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ABSTRACT 

This  research  discusses  a  program  which  aids  the 
user  of  an  automatic  programming  system  (APS)  In  the 
"debugging"  of  his  model  of  his  problem  situation.  In 
essence,  the  user  must  make  sure  that  he  and  the  APS  mean 
the  same  thing  by  the  description  of  the  problem  which  the 
APS  Is  to  solve.  The  problem  domain  considered  In  this 
thesis  Is  that  of  "business  games"  (I.e.,  the  management 
simulation  games  which  are  used  as  a  learning  tool  In  the 
study  of  management).  A  language  for  describing  models  of 
these  games  Is  presented.  The  paper  then  describes  the 
program's  methods  of  simulating  and  finding  bugs  In  models 
written  In  this  language.  Important  aspects  of  the  program's 
problem-solving  approach  to  debugging  are  Its  Internal 
knowledge  of  "bugs"  and  of  user  Intention  within  the  model. 
This  Internal  knowledge  stresses  the  Importance  of  bugs 
arising  from  the  Interaction  of  submodels  within  the  model. 
Some  details  of  the  program's  Implementation  (In  the 
Connlver  language)  are  discussed.  The  necessity  of 
"model -debugging"  In  automatic  programming  Is  emphasized. 
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1  Introduction 

The  purpose  of  this  research  Is  to 
explore  a  methodology  for  debugging  certain  models  of  real 
world  situations.  The  models  considered  here  consist  of 
groups  of  well-defined  submodels.  The  submodels  themselves 
are  fairly  structured;  the  Interaction  between  submodels  Is 
not.  In  this  paper  I  will  discuss  a  program  which  uses  the 
techniques  of  goal -programm! ng  to  explore  the  Interactive 
behavior  of  a  given  model.  The  basic  Idea  is  that  a  bug  In 
the  model  will  give  rise  to  a  "problem".  ,  The  program  then 
tries  to  solve  this  problem  in  an  environment  defined  and 
constrained  by  the  model.  Those  steps  at  which  the 
program's  problem-solving  process  encounters  constraints 
caused  by  unintended  Interaction  of  submodels  suggest 
possible  locations  of  bugs  within  the  model. 

To  a  large  extent,  the  problems  of  this 
research  are  "artificial  intelligence"  problems.  That  Is, 
the  research  problems  Involve  representation  of  knowledge  in 
a  form  which  useful  to  the  probl  em- sol ve r,  and 
representation  f  the  problem-solving  process  as  a  computer 
program.  The  remainder  of  this  paper  will  deal  with  one 
solution  of  these  problems  for  a  program  which  debugs  models 
of  management  situations.  This  section  will  present  a  more 
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complete  explanation  of  the  area  of  mode  1 -debugg I ng  as  I  see 
It.  The  next  section  prov.des  an  overview  of  the  whole 
debugging  process  In  the  context  of  a  detailed  example. 
Later  sections  develop  some  Ideas  about  bugs, 
problem-solving,  goal -programming,  and  the  program  Itself. 

1 . 1  Define  "define" 


l.i.i  What  is.  a  pod  el  ? 


Marvin  fllnsky  describes  the  concept  of  a 

"mocel"  as  follows: 

If  a  creature  can  answer  a  question 
about  a  hypothetical  experiment  without  actually 
performing  it,  then  It  has  demonstrated  some 
knowledge  about  the  world.  For  his  answer  to  the 
question  must  he  an  encoded  description  of  the 
behavior  (Inside  the  creature)  of  a  sub-machine  or 
"model"  responding  to  an  encoded  description  of 
the  world  situation  described  by  the  question. 

We  use  the  term  "model"  In  the  following 
sense:  to  an  observer  B,  an  object  A*  Is  a  model 
of  an  object  A  to  the  extent  that  B  can  use  A*  to 
answer  questions  that  Interest  him  about  A.  |12| 


For  the  purpose  of  this  research,  the  term  "model"  will  be 
used  In  a  much  less  general  and  more  concrete  way. 
Specifically,  the  program  discussed  here  requires  that  the 
"encoded  description"  be  of  a  particular  pre-deffned  type, 
that  the  kinds  of  world-objects  "A"'  to  be  modelled  belong  to 
a  very  limited  class  of  things,  and  that  "BH,s  questions  of 
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Interest  be  sharply  restricted. 

After  this  section,  the  term  "model" 
will  be  used  to  refer  to  a  user-defined  collection  of 
constructs  In  a  model  specification  language  (MSL) 
(presented  In  section  4.1)  which  describes  a  "real-world" 
management  system.  (1)  For  now,  suffice  it  to  say  that  a 
''model"  Is  a  user's  description  of  his  system  of  Interest. 
That  Is,  the  user  thinks  that  the  model  describes  his 
system--actua 1 1 y,  the  model  contains  bugs. 

1.1.2  Midi  js  debugging? 

When  a  model's  performance  Is  not  what 
the  user  expects,  we  say  that  the  model  has  a  "bug"  (see 
section  3).  Ti»e  process  of  finding  what  causes  the 
discrepancy  between  performance  and  expectation  Is  called 
"debugging".  It  Is  the  nature  of  complex  processes  that  the 
cause  of  a  discrepancy  may  be  related  to  the  manifestation 
of  the  discrepancy  only  through  a  seemingly  Intricate  chain 
of  reasoning.  The  purpose  of  this  research  Is  to  write  a 
program  which  knows  the  necessary  kind  of  reasoning  to  go 
from  the  manifestation  to  the  cause  of  a  bug. 


(1) 

Actually,  a  real-world  business  game . 
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In  order  to  Incorporate  this  reasoning 
process#  the  program  must  have  knowledge  about  MSL  models 
(see  4.1)#  the  kinds  of  burs  that  occur  In  MSL  models  (see 

3.3) #  how  these  bugs  manifest  themselves  (see  4.4.2)#  and 
how  the  causes  are  related  to  the  manifestations  (see 

4.4.3) .  Of  course#  this  Is  In  some  sense  the  "whole  story"; 
before  launching  Into  It#  It  might  be  a  good  Idea  to  examine 
our  reasons  for  worrying  about  mode  1 -debugg ! ng  In  the  first 
pi  ace . 
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will  describe  a  process  which  seems  only  barely  related  to 
the  grandiose  exaltations  of  the  previous  paragraph.  For 
one  thing,  the  extremely  close  Interaction  between  model 
debugging  and  formation  will  be  greatly  restricted  to  allow 
examination  of  the  debugging  process  Itself.  Also,,  the 
restrictions  Inherent  (1)  In  the  "show  a  working  program" 
approach  of  this  research  make  the  class  of  problems  seem 
trivial  when  compared  to  the  overall  problem  of 
model -debugging. 

Although  I  could  now  claim  that  the 
validity  of  this  research  effort  Is  that  It  provides  an 
Initial  Investigation  Into  a  very  hairy  area  (the  usual 
Induction  step  In  artificial  Intelligence  theses),  !  will 
move  In  more  practical  directions.  (Of  course,  I  hope  for 
the  higher  parallels  all  along.)  Specifically,  |  consider 
the  Importance  of  the  kind  of  model -debugging  actually 
presented  here  for  the  new  field  of  automatic  programming. 

1 . 2 . 2  Mfl.te.1  Id  automatic  programming 


(1)  These  restrictions  are  "Inherent"  at  this  stage  of  our 
knowledge,  at  this  stage  of  my  knowledge,  and  In  the 
exigencies  of  churning  out  a  Master's  thesis.  Certainly, 
there  are  no  Inherent  restrictions  In  the  capability  of 
computers  to  Incorporate  the  process. 
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Automatic  prop;  ramming  Is  the  art  of 
providing  a  computer  program  (an  "automatic  programming 
system"  (APS))  which  takes  as  Input  some  user-amenable 
description  of  a  task  and  produces  as  output  computer 
programs  to  accomplish  that  *-ask.  The  user's  description  of 
his  task  Is  his  "model"  In  the  sense  described  In  1.1.1. 
This  Is  the  "model"  which  the  program  described  In  this 
thesis  must  debue. 


But  why  worry  about  model-debugging? 
Why  not  let  the  user  specify  something,  let  the  system 
generate  a  solution  program,  and  simply  leave  It  to  the  user 
to  respeclfy  the  problem  If  he  doesn't  like  the  results? 
There  are  several  answers  to  this  question,  some  obvious, 
others  not  so  obvious.  Basically,  the  reasons  for  providing 
sophisticated  model -debugg Ing  aids  revolve  around 
considerations  of  efficient  use  of  the  APS,  ease  of  use  of 
the  APS,  ease  of  construction  of  the  APS,  and  "safety"  In 
the  use  of  the  APS. 


mode  1 -debugg Ing  Is 
actually  writing 
description  Is  In) 
worthwhile  making 
what  the  problem  Is 


The  most 
that  since 
the  solution 
Is  a  rather 
sure  that  the 
before  the  APS 


obvious  reason  for 
code-generation  (l.e., 
program  after  the  task 
arduous  process.  It  Is 
user  and  the  APS  agree  on 
actually  writes  programs 
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to  solve  the  problem.  This  idea  of  pre-code-gene rat  Ion 
debugging  Is  as  old  as  compilers,  and  Is  fairly  well 
understood.  (1) 

A  related  but  not  quite  so  obvious 
reason  for  providing  mode  1 -debugg Ing  aids  in  an  APS  Is  to 
make  the  system  easier  to  use.  This  Is  especially  necessary 
In  an  APS  like  Protosystem  i  |9|  which  attempts  to  provide 
problem-solving  expertise  to  aid  the  user.  The  point  Is 
that  the  APS  Is  designed  to  provide  problem-solving 
knowledge  for  a  user  who  Is  not  at  all  adept  In  computer 
problem-solving.  To  help  him  design  a  description  of  his 
task  and  then  not  to  aid  him  in  debugging  that  description 
seems  like  providing  not  much  help  at  all:  descriptions  of 
complex  problems  "always"  have  bugs,  and  finding  them  Is 
usually  as  sophisticated  a  task  as  writing  the  description 
In  the  first  place.  (2)  Thus,  1  beleve  that  an  APS  that 
does  not  provide  model -debugg I ng  aid  would  be  difficult.  If 
not  Impossible,  to  use. 

Supposing,  then,  that  some  kind  of 


(1)  The  actual  debugging  of  models  may  be  quite  different 
from  the  debugging  of  source  code,  but  the  reason  for  doing 
so  Is  the  same  In  this  case. 

(2)  Statistics  have  shown  that  about  50%  of  the  time  In 
large  system  development  is  spent  In  debugging  |2|. 
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debugg I ng  a!d  Is  necessary,  how  should  It  be  Interfaced  with 
the  user  and  with  the  APS?  The  answer,  1  think.  Is  that 
debugging  should  occur  when  the  system's  knowledge  of  the 
user's  problem  Is  still  at  a  high  level  of  symbolic 
description.  That  Is,  prior  to  code  generation.  This 
leaves  the  debugging  effort  In  the  realm  of 
model -debugging.  The  reason  that  It  Is  Important  to  keep 
debugging  at  a  high  symbolic  level  Is  to  keep  the  design  of 
the  APS  as  simple  as  possible.  It  Is  quite  difficult  to 
maintain  the  links  between  mistakes  which  occur  at  low 
levels  of  description  (e.g.,  programs)  and  their  high-level 
causes.  Certainly  the  user  cannot  be  responsible  for 
maintaining  these  links.  If  the  APS  te 1 1 s  h Im  that  "an 
Illegal  reference  was  generated  from  location  11437",  we 
cannot  expect  hln  to  have  any  notion  of  what  went  wrong  with 
his  model  description.  In  fact,  the  construction  of  an  APS 
which  could  make  this  connection  between  the  bug's 
manifestation  and  Its  cause  would  be  extremely  difficult. 
It  seems  much  more  reasonable  to  carry  on  debugging  at  a 
high  level  of  symbolic  description  which  both  the  user  and 
the  APS  can  understand  In  terms  of  the  user's  model. 

Finally,  there  Is  a  very  special  problem 
which  arises  In  connection  with  the  use  of  the  APS.  The 
user  begins  to  develop  a  dependency  on  the  APS  and  to  trust 
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the  results  of  the  solution  programs.  When  the  system  Is 
more  expert  then  the  user  (as  Is  the  case  In  Protosystem  1), 
the  user  may  even  trust  results  v/hlch  "common  sense"  (l.e., 
previous  experience,  educated  guesses,  etc.)  tells  him  are 
wrong.  In  these  circumstances.  It  Is  of  paramount 
Importance  that  the  user  be  sure  that  the  APS  has  a  correct 
understanding  of  his  model.  Other  than  the  mode  1 -dehugg Ing 
subsystem  within  the  APS,  there  may  he  no  source  of  feedback 
which  enables  the  user  to  find  out  that  there  Is  anything 
wrong  at  all  .  (1) 

The  model -dehugg Ing  facility  has  sole 
responsibility  for  helping  the  user  to  understand  what  Is 
wrong  with  his  model  In  terms  of  the  model--|.e..  In  the 
only  terms  the  user  understands.  An  APS  which  does  not 
provide  a  facility  for  Interactive  discussion  of  the  model's 
assumptions  and  their  ramifications  Is  a  dangerous  tool 
Indeed.  Thus,  the  user  must  always  have  some  means  of 
observing  the  effects  of  the  assumptions  In  the  model  and 
for  making  sure  that  the  APS  "knows  what  he  means".  The 
model-debugging  subsystem  of  the  APS  provides  the  necessary 
mechan I sm. 

Therefore,  for  reasons  of  efficiency. 


(1)  The  output  code  and.  In  many  cases,  the  assumptions 
underlying  Its  generation  will  be  Incomprehensible  to  the 
average  user. 
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usability,  and  safety,  a  model -debugging  facility  Is  a 
necessary  part  of  an  automatic  programming  system.  Still, 
the  general  problem  of  mode  1 -debugg I ng  In  automatic 
programming  Is  much  too  larre  to  be  considered  here.  In 
the  next  section,  I  will  explain  the  particular  subdomain  of 
automatic  programming  I  will  attack,  and  my  reasons  for 
choosing  It. 


1.3  Details,  deta I  I  s 
1.3.1  Restriction  the  WQM 


The  program  described  In  this  thesis  Is 
specialized  to  work  on  models  chosen  from  the  "world  of 
business  games"  (WOBG).  By  this  1  mean  an  environment  In 
which  the  concepts  common  to  business  games  are  the  stock 
knowledge.  There  are  several  reasons  for  choosing  this 
domain  of  Interest:  (1)  the  models  are  sufficiently 
structured  to  be  formally  expressible,  but  are  not  so 
structured  that  they  are  susceptible  to  mathematical 
analysis;  (2)  the  Interaction  of  submodels  Is  the  most 
Interesting  and  complex  aspect  of  the  model;  (3)  this  Is  one 
of  the  few  domains  which  Is  both  reasonable-sized  and 
"rpal -world"  (In  the  sense  that  there  Is  a  great  deal  of 


Interest  In  It  Independent  of  this  research);  (4)  It  Is  a 
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natural  subdomain  of  the  "world  of  business"  (nob)  of 
Protosystem  I  |9|. 

Models  In  various  domains  differ  greatly 
In  the  amount  of  "structure"  present  In  the  description  of 
the  model.  By  "structure"  I  mean  clearly  defined  rules  of 
construction  and  constraints  on  elements.  The  methods  used 

In  this  research  require  well-defined  models.  However,  If 

the  model  Is  "too  well-defined",  debugging  becomes 
Interesting,  or  Is  more  easily  accomplished  by 

mathematical  tools.  The  WO EC  seems  to  have  just  the  right 

level  of  structure.  Since  the  Idea  of  model  1 Ing  business 
systems  Is  well  established,  there  exist  a  variety  of 
formalisms  for  expressing  business  models.  These  modelling 
formalisms  are  even  more  clearly  defined  for  business  games. 
The  very  Idea  of  a  game  Is  to  have  a  Precise  set  of  elements 
and  rules  for  manipulating  them.  Nonetheless,  understanding 
and  debugging  models  of  business  games  Is  by  no  means 
trivial.  There  Is  good  evlde.ce  that  users  of  even  the 
simplest  of  business  games  have  very  poor  and  "buggy"  models 
of  what  Is  going  on  |3|,|6|,|8|.  The  main  reason  for  this 

Is  the  complexity  of  the  Interaction  between  submodels  In 
business  games, 

I  am  particularly  Interested  in 

debugging  models  In  which  Interaction  of  subparts  is  a  major 


Pape  16 


factor  In  model  complexity.  Most  model -worlds  which  have 
been  I nvest Igated  In  artificial  Intelligence  research  (e.g., 
the  "blocks  world"  |21|)  have  few  complex  Interdependencies. 
Existing  Interaction  problems  fend  to  be  downplayed  In  order 
to  emphasize  other  aspects  of  the  models.  (For  example, 
see  Wlnograd's  "solution"  to  the  "flndspace  problem"  In 
I21|;  cf.  1 1 7 1 . )  I  wish  to  explore  the  other  end  of  the 
Interdependency  scale;  l.e.,  hlrhly  Interactive  models.  (1) 
The  kind  of  models  which  the  program  described  In  this 
research  Is  designed  to  debug  are  those  In  which  the  user 
has  a  good  unde rstand I ng  of  the  various  parts  of  the  model, 
but  do»s  not  understand  how  these  parts  (which  I  will  call 
"submodels")  Interact  with  each  other.  (2) 

In  fact,  al 1  of  the  bugs  which  the 
program  Is  designed  to  *lnd  arise  from  Interaction  of 
submodels  (see  section  3.3).  Business  games  have  very 


(1)  Real  world  situations  presumably  fall  somewhere  In 
between  these  two  extremes.  However,  I  wl 1 1  devote  a 
considerable  amounc  of  space  (all  of  section  3)  to  an 
examination  of  how  Interaction  of  submodels  Is  the  major 
complexity  factor  In  real  world  situations  (In  particular. 
In  large  business  organizations),  and  how  these  real  world 
Interdependency  problems  form  the  "semantic  roots"  of 
similar  problems  In  the  toy-world  used  In  this  research.  I 
am  hoping  to  motivate  an  Interest  In  the  "Interaction  bugs" 
which  will  preoccupy  the  remainder  of  the  thesis. 

(2)  1  believe  that  this  Is  a  large  and  Important  class  of 
models,  including  models  of  "systems"  with  we  1 1 -unde rstood 
el ements  ( see  I  3 | ) . 
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precisely  defined  elements  (see  the  example  game  In  Appendix 
A).  However,  the‘e  elements  Interact  with  each  other  to 
the  extent  that  understand Inr  how  the  "whole  system"  (l.e., 
all  of  the  Interacting  parts)  works  Is  a  major  challenge  to 
the  players.  Thus,  since  poorly  understood  Interaction  of 
submodels  Is  the  major  source  of  hues  In  this  domain,  the 
WORfi  forms  an  excellent  testing  ermine!  for  my  program. 

Business  games  also  have  the  Important 
property  of  being  Interesting  In  their  own  right.  Playing 
and  understanding  business  games  Is  considered  to  be  an 
Important  activity  at  many  schools  of  management  throughout 
the  world.  There  Is  therefore  little  danger  of  being 
accused  of  designing  a  program  which  works  only  In  an  hoc 
problem  domain.  Furthermore,  since  people  are  used  to 
trying  to  model  business  games  for  themselves,  they  can 
appreciate  the  efforts  of  a  program  which  aids  In  the 
debugging  of  such  models.  This  "real  world"  flavor  of 
business  games  Is  one  of  their  most  important  properties  for 
this  research. 

Finally,  the  WOGG  Is  a  natural  subdomain 
of  the  WOB  of  Protosystem  I.  This  Is  useful,  first  of  all, 
because  It  allows  a  certain  Inheritance  of  philosophy  and 
technique  from  the  larger  project.  More  Importantly, 
though.  It  enables  the  model -debugger  presented  here  to  be 
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seen  In  the  context  of  a  large  automatic  programming  system. 
Since  the  ra I  son  d’etre  of  my  program  Is  use  in  an  APS,  this 
connection  with  Protosystem  I  is  an  important  aspect  of  the 
research.  m 

Therefore,  the  basic  philosophy  of 
model -debugg  ing  presented  here  will  be  applied  to  models 
chosen  from  the  world  of  business  games.  In  order  to  show 
that  my  basic  Ideas  about  debugging  are  Indeed  "working 
ideas",  I  have  written  a  program  which  uses  these  concepts 
to  debug  actual  models  of  business  games. 


1.3.2  Iil£  rile.  ol  _Lh£  program  Id.  JLh£  thesis 


The  program  presented  In  this  thesis 
serves  several  purposes:  Illustration  of  Important  methods, 
demonstration  of  the  workability  of  the  techniques,  and 
discussion  of  design  Issues  for  mode  1 -debugging  programs. 
Certainly,  the  major  use  of  the  program  in  the  thesis  Is  to 
provide  examples  for  the  debugging  theory  developed  In  the 
research.  All  the  major  debugging  Ideas  are  Illustrated  by 
a  scenario  from  the  working  program.  As  for  the  second  use 
of  the  program,  a  little  care  Is  necessary  In  explaining  the 
"proof"  value  of  the  program  In  the  thesis.  It  Is  often 
contended  that  working  programs  prove  the  utility  of  the 
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theories  that  they  represent.  This  Is  true,  so  long  as  the 
reader  Is  careful  not  to  use  some  sort  of  false  Induction 
principle  to  Infer  too  much  from  what  the  program  actua 1 1 v 
■dfiS S ♦  As  is  almost  always  the  case,  the  program  In  this 
thesis  can  actually  do  only  a  subset  of  what  Is  talked 
about.  I  will  always  make  It  clear  what  the  program  can 
and  cannot  do,  how  the  program  can  be  extended  to  do  more. 


etc. 


The  reader  should  draw 


genera  1 


concl us  I ons--ca ref ul 1 y--f rom  this  information, 


Using  this  "program-as-l  1  1 ustrator" 
Philosophy  of  presentation,  I  will  now  launch  Into  a 
detailed  example  of  program  operation  on  a  simple  model. 
This  will  hopefully  give  the  reader  a  good  basic  Idea  of 
what  the  rest  of  the  thesis  has  to  say.  The  issues  raised 
In  the  example  and  the  example  Itself  will  be  discussed  at 
length  In  the  rest  of  the  thesis,  each  aspect  of  the  problem 
appearing  In  Its  logical  section  (see  table  of  contents). 
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2  Just  la  give  mu  mi  idaa. . . 

The  Important  thing  to  keep  In  mind 
about  this  program  Is  that  It  finds  the  causes  of  bugs  In 
much  the  same  way  that  people  (or  Sussman's  HACKER  1 1 8 1 )  do: 
by  trying  to  solve  problems — and  falling.  In  this  section  I 
will  present  the  complete  works  of  my  program  In  connection 
with  a  very  simple  example.  A  lot  of  new  notation  Is 
presented  here;  please  don't  get  bogged  down  In  It.  I 
present  It  here  only  to  avoid  vagueness  In  showing  what  the 
program  actually  works  with.  More  complete  explanations  of 
all  the  notation  (and  Indeed,  the  entire  example)  appear  In 
the  appropriate  sections  later  on.  This  discussion  focuses 
on  what  the  program  means  by  a  "bug"  and  on  some  of  the 
procedures  used  to  go  from  the  manifestation  to  the  cause  of 
a  bug.  Neither  the  procedures  nor  the  descriptive 
mechanisms  used  by  the  program  are  discussed  In  detail  here. 
Philosophical  Issues  about  representation  of  knowledge  In 
the  program  and  goal -programml ng  are  eschewed  completely. 
This  Is  a  quick  "Introduction  by  doing"  to  the  methodology 
of  the  program. 

Suppose  the  user  presents  the  program 
with  the  following  (tiny)  model: 
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.  Consider  the  following  model 

A/a1e  ,ls  a  Probabilistic  occurence 
which  depends  only  on  the  amount  of  advertising 
done.  Advertising  costs  $3000  per  page  and  Is 
good  for  one  quarter.  I  buy  three  pages  of 
advertising  per  quarter#  If  the  money  to  do  so  Is 
available.  Sales  take  place  during  sales  calls. 
There  Is  one  call  per  salesman  per  quarter.  A 
customer  never  buys  more  than  one  unit.  If  a  unit 
is  sold#  the  company  records  $5000  In  accounts 
receivable  (A-R)#  which  Is  not  collectable  for 
another  two  quarters.  At  any  time#  a  salesman  has 
a  5/0  chance  of  quitting.  If  a  salesman  quits#  a 
new  man  Is  hired.  After  three  months  of 
training#  this  man  becomes  a  salesman  and  may 
start  making  calls.  Both  salesmen  and  trainees 
are  paid  $1000  per  quarter.  Trainees  also  have  a 
oZ  chance  of  quitting  at  any  time. 


The  user  would  Input  this  model  Into  the  program  with  the 
model  specification  language  presented  In  section  4.1.  |n 
these  MSL  terms#  the  model  looks  like: 

(♦ACTIVITY  HIRING 

(♦PREREQUISITES  (♦PRESENT  (1000  CASH))) 
(♦SCHEDULE  ON  QUIT) 

(♦PRIORITY  2) 

(♦OUTPUT  (SOME  TRAINEE)) 

(♦TAKES  0) 


(♦ACTIVITY  ADVERTISING 

(♦PREREQUISITES  (♦PRESENT  (3000  CASH))) 
(♦SCHEDULE  3) 

(♦TAKES  1) 

(♦PRIORITY  3) 

( ‘OUTPUT  (1  PAGE-OF -ADVERTISING)) 


(♦ACTIVITY  TRAINING 

(♦PREREQUISITES 

(AND 


) 


(♦PRESENT  (1000  CASH)) 
(♦PRESENT  (SOME  TRAINEE)) 
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(♦TAKES  3) 

(♦OUTPUT  (SOME  SALESMAN)) 


(♦ACTIVITY  SALES-CALL 

(♦PREREQUISITES 

(AND 


(♦PRESENT  (1000  CASH)) 
(♦PRESENT  (1  UNIT)) 
(♦PRESENT  (SOME  SALESMAN)) 


(♦TAKES  1) 


(♦ACTIVITY  COLLECTION 

(♦PREREQUISITES  ( *PRESENT  (5000  A-R))) 
(♦TAKES  2) 

(♦OUTPUT  (5000  CASH)) 

) 

(♦EVENT  SALE 

(♦CONDITIONS  SALES-PROBAB I L I TY) 
(♦ACTIVITIES  (SALES-CALL) 

(♦OUTPUT  (5000  A-R)) 

) 

) 

(♦EVENT  QUITTING 

(♦CONDITIONS  QUITTING-PROBABI LITY) 
(♦ACTIVITIES  (SALES-CALL) 

(♦CANCEL) 

(♦REMOVE  (THAT  SALESMAN)) 

) 

(♦ACTIVITIES  (TRAINING) 

(♦CANCEL) 

(♦REMOVE  (THAT  TRAINEE)) 

) 


(♦FUNCTION  SALES-PROBABI LITY 

( * ARGUMENTS  ( PAGE-OF -ADVERT I S I NG ) ) 
(♦RETURN  ad-funct Ion) ) 

) 


(I  will  not  show  the  exact  nature  of 
"ad-functlon",  as  It  Is  a  *TABLE  construct  (see  4.1)-- 


worry  about 


j  ust 
here 


a  bunch  of  numbers  that  we 
(see  Appendix  B) . ) 


shouldn't 


Now  suppose  the  user  gives  the  program 

the  foil ow I ng : 

(♦SIMULATE  4  1 

((30000  CASH) 

(50  UNIT) 

(DON  SALESMAN) 

(MARK  SALESMAN) 

(STEVE  SALESMAN) 

(BILL  SALESMAN) 

(.05  QUI TTI NG-PROBAB I L I rY) )  ) 


or.  In  words,  simulate  the  mode,  for  4  barters,  showing  a 
tlme-sl Ice  every  quarter,  and  with  the  s,ven  Inltla,  values 
Before  considering  the  actions  of  the  program,  ,t  „ 
worthwhile  to  note  a  few  things. 

First,  observe  that  the  the  user  has 

given  the  model  (50  UNIT)  as  an  Initial  resource.  This  Is  a 

typical  example  of  a  mode, -testing  technique:  adding  slack 

to  decouple  submodels.  Presumably,  UNIT  |s  something 

created  by  another  submodel  which  the  user  does  not  wish  to 

consider  at  tnls  time.  The  user  effectively  removes  this 

"other  submodel"  by  making  sure  that  the  submodel  Is  never 

limited  by  the  amount  of  UNIT  avaIlahio  (Tk  nrw^ 

win  i  available.  (The  PRODUCTION 

submodel  which  creates  UNIT'c  ic  .h  , 

s  JNM  s  ,s  shown  In  Appendix  B.)) 

Second,  note  that  we  are  making  an 

Imp! I c I t  assumption  about  what  the  user  w, 1 1  do  with  the 


A 
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simulation  after  It  Is  presented  by  the  program.  We  are 
assuming  that  he  will  be  either  satisfied  or  dissatisfied 
with  the  result  (1)  .  If  he  Is  dissatisfied,  he  will  express 
his  expectation  to  the  system  In  the  form  of  a  goal.  This 
In  It  let os  the  debugging  process.  At  this  time,  let  us 
rejoin  our  example.  In  progress. 

The  first  action  of  the  program  Is  to 
simulate  the  model  as  the  user  requests.  If  the  user's 
expectation  Is  fulfilled,  no  further  action  will  be  taken 
until  the  user's  next  request  for  simulation.  If  his 

expectation  Is  not  met,  the  program  will  help  him  find  the 
bug  In  the  model . 

The  requested  simulation  Is  shown  below. 
The  representation  used  here  (and  throughout  the  thesis) 
should  be  seen  as  a  graphical  description  of  the  complex  of 
list  structure  which  the  program  ures  to  describe  simulation 
histories.  Every  part  of  the  diagram  has  an  analog  In  the 

Connlver  1 20 1  representation  of  the  program  (see  section 
4.2). 


are  also  assuming  that  the  user  Is  a  good  judge  of 

Th?  ’ °v®ra  11  Performance  of  the  system  he  Is  trying  to  model 

thir  It  °f  co“rse  not  ^consistent  with  our  basic  premise 

svsLn  fan^th  V  n°t  fUl]y  understa"d  the  workings  of  the 

art Ravine  ^  35  UP  ln  h,S  model)-  Rather,  we 

aTe  raying  that  the  user  knows  pretty  well  what  rh*»  mrtr|0i 

shoujd^o,  but  .s  having  trouble  ma^'n^the  iodel  do^hat  U 
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SIMULATION-HISTORY 


♦TIME-SLI CE  0* 

RESOURCES; 

SALESMEN:  DON,  STEVE, MARK,  BILL 
CASH;  30000 

UNITS:  50 


♦TIME-SLICE  1* 

SALESMEN:  PON,  STEVE,  MARK,  BILL 

CASH: 

17000 

UNITS: 

48 

A-R: 

10000 

SCHEDULED 

♦ACTIVITY'S: 
SALES-CALL  (DON) 

SALES-CALL  (STEVE) 

SALES-CALL  (MARK) 

SALES-CALL  (BILL) 

ADVERTISING 

ADVERTISING 

ADVERTISING 

COLLECTION 

(TIME-LEFT  = 

2) 

COLLECTION 

(TIME-LEFT  = 

2) 

♦EVENT'S: 

SALE  (BILL) 

SALE  (DON) 

♦TIME-SLICE  2* 

RESOURCES 

• 

• 

SALESMEN:  DON, MARK, 

BILL 

CASH: 

5000 

UN  1 TS : 

47 

A-R: 

TRAINEE:  G0001 

15000 

SCHEDULED 

♦ACTIVITY'S: 
SALES-CALL  (DON) 
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SALES-CALL  (MARK) 
SALES-CALL  (BILL) 
ADVERTISING 
ADVERTISING 
ADVERTISING 

COLLECTION  (TIME-LEFT  =  1) 
COLLECTION  (TIME-LEFT  =  1) 
COLLECTION  (TIME-LEFT  =  2) 
HIRING 

TRAINING  (TIME-LEFT  =  3) 


*£Y£N,TI  s,: 

SALE  (MARK) 
QUITTING  (STEVE) 


♦TIME-SLICE  3* 


RRESOURCES : 

SALESMEN: 
CASH: 
UNITS: 
A-r  • 

TRAINEE: 


DON,  MARK,  BILL 
2000 
46 

10000 

G0001 


SCHEDULED  ♦ACTIVITY’S: 

SALES-CALL  (DON) 

SALES-CALL  (MARK) 
SALES-CALL  (BILL) 
ADVERTISING 
ADVERTISING 
ADVERTISING 

COLLECTION  (TIME-LEFT  =  2) 
COLLECTION  (TIME-LEFT  =  1) 
TRAINING  (TIME-LEFT  *  2) 


♦EVENTS: 

SALE  (BILL) 


♦TIME-SLICE  4* 


SALESMEN: 

CASH: 

UNITS: 

A-R: 


DON, 


MARK,  BILL 
1000 
45 

10000 
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TRAINEE:  G0001 

SCHEDULED  ^ACTIVITY'S: 

SALES-CALL  (DON) 

SALES-CALL  (MARK) 
SALES-CALL  (BILL) 
ADVERTISING 

COLLECTON  (TIME-LEFT  =  2) 
COLLECTION  (TIME-LEFT  =  1) 
TRAINING  (TIME-LEFT  =  1) 


* EVENT'S: 

SALE  (MARK) 


The  simulation  has  resulted  In  5  SALE's. 
Suppose  that  the  user  expected  6.  There  Is  a  bug  In  the 
model --but  where?  Note  that  the  model  runs  out  of  CASH  In 
the  last  quarter  (and  therefore  cannot  schedule  ail  three 
ADVERTISING  *ACT I V  I TY ' s ) .  However,  the  bug  Is  not  "NOT 
ENOUGH  CASH".  Rather,  this  effect  Is  svmptomat i c  of  the 
bug.  Most  of  the  effort  of  the  program  Is  to  point  out 
bugs,  not  their  symptoms.  But  this  requires  problem-solving 
In  the  context  of  the  simulation  history.  Back  to  the 
actual  action  of  the  program... 

The  user  notes  that  there  were  only  5 
SALE's  rather  than  the  expected  6.  In  order  to  try  to 
rectify  things,  the  user  gives  the  system 

(♦GOAL  (INCREASE  SALE  D) 

The  program  Is  now  In  the  debugging  business.  It  must  try 
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to  solve  the  problem  of  Increasing  the  number  of  SALE's  In 
the  context  of  the  given  simulation  history.  The  places  at 
which  It  encounters  dubious  constraints  In  the  simulation 
environment  are  Its  possible  locations  for  bugs. 

The  program  uses  the  model  and  the 
simulation  history  to  perform  the  requisite  problem-solving 
activity  for  each  goal  as  It  Is  presented.  This  may  be 
thought  of  as  asking  two  questions  of  the  model  and  the 
s Imul at  I  on : 

(1)  Why  didn't  you  do  this  before? 
and,  !f  there  Is  no  good  reason, 

(2)  How  could  we  do  this? 

The  method  of  asking  and  receiving  answers  to  these 
questions  Is  best  explained  by  continuation  of  the  example. 

The  first  goal  (given  by  the  user)  Is 
(♦GOAL  (INCREASE  SALE  1)) 

Since  this  goal  was  given  by  the  user,  the  first  question  Is 
not  asked.  However,  the  second  question  Is  asked.  How  can 
we  Increase  the  number  of  SALE's?  By  examining  the  model 
and  using  the  logic  of  INCREASE  (explained  In  section 
4.4.1),  we  see  that  one  way  to  Increase  SALE's  Is  to 
Increase  the  probability  of  a  SALE  occurlng.  Thus,  the 
system  generates  a  new  goal 
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(♦GOAL  (INCREASE  SALES-PROBAB I L I TY) ) 

Now  the  program  asks  question  number  one:  why  wasn't 
SALES-PROBAB I L I TY  higher  In  the  first  place?  The  program 
looks  a t  the  simulation  history  and  notes  that  the 
SALES-PROBAB I L ! TY  was  at  a  low  In  time-slice  4.  Why  Is  It 
so  low?  There  was  not  enough  ADVERTISING,  the  program 
determines.  This  Is  a  BAD  REASON:  the  model  was 
RESOURCE-LIMITED.  Okay,  how  can  we  get  the  necessary 
ADVERTISING?  In  order  to  Investigate  this  question,  the 
program  generates  a  new  goal 

(♦GOAL  (SCHEDULE  2  ADVERTISING  4)) 

which  means  "try  to  schedule  2  ADVERTISING  ^ACTIVITY'S  In 
time-slice  4".  (The  fact  that  we  need  2  ADVERTISING 
♦ACTIVITY'S  Is  presumably  due  to  the  e:cact  nature  of 
ad- , unct I  on",  and  will  not  be  discussed  here.)  Again,  the 
program  asks  why  the  ADVERTISING  ‘ACTIVITY'S  were  not 
scheduled  In  the  first  place.  The  answer  Is  that  there  was 

not  enough  CASH;  still  RESOURCE-LIMITED,  so  we  pursue  this 
line  with: 

(♦GOAL  (INCREASE  CASH  6000  4)) 


By  again  asking  the  questions  and  forming  new  goals,  the 
program  forms  the  following  ‘GOAL  line: 

(♦GOAL  (INCREASE  CASH  6000  4)) 
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(♦GOAL  (SCHEDULE  2  COLLECTION  4)) 

(♦GOAL  CALLOW  2  SALE  2)) 

(♦GOAL  (SCHEDULE  3  ADVERTISING  2)) 

("ALLOW"  rather  than  "SCHEDULE"  because  SALE  Is  an  *EVENT. ) 
Note  that  we  are  back  to  SCHEDULlng  ADVERTISING.  Are  we  In 
some  kind  of  loop?  No#  we  are  moving  back  In  time. 
Furthermore,  this  time,  when  we  ask  why  we  didn't  schedule 
three  more  ADVERTISING  *ACTIVITY's  In  time-slice  2,  we  find 
that  the  ireasori  Is  that  the  user  told  us  not  to  (via  his 
♦SCHEDULE  specification  In  the  ADVERTISING  *ACTIVITY  (see 
page  17)).  Thus,  ADVERTISING  Is  SCHEDULE-LIMITED  !n 
time-slice  2.  This  Is  a  GOOD  REASON,  and  the  program 
terminates  action  on  this  line  of  thought.  Nonetheless,  it 
saves  Information  about  the  terminated  line.  If  no  more 
"likely"  bug  is  found,  the  program  will  tell  the  user  that 
his  *SCHEDULE  specification  for  ADVERTISING  Is  Insufficient 
to  allow  the  mode!  to  meet  his  expectations.  In  the 
meantime,  however,  the  program  explores  the  model  for  more 
likely  bugs.  The  program  does  this  by  "backing  up"  (1)  some 

(1)  This  is  not  automatic  backup  in  the  PLANNER  sense.  The 
program  backs  up  only  in  certain  cases,  and  only  under 
program  control.  More  Importantly,  the  effects  of  the 
"backed-over"  *G0AL's  are  "undone"  only  In  the  corLtfiXt  ol 
the  simulation  history.  The  terminated  lines  must  be  saved 
for  later  examination  by  the  program.  This  is  essential  for 
handling  the  *GR0UP  constructs  discussed  later  in  the 
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and  trying  a  different  line  of  attack. 

In  this  case,  the  program  checks  to  see 
If  there  Is  another  way  to  accomplish 

( *GOAL  (ALLOW  2  SALE  2)) 

Using  Its  usual  question-asking  procedure,  the  program  finds 
the  al ternate  1 Ine 

( *GOAL  (ALLOW  2  SALE  2)) 

(♦GOAL  (INCREASE  SALES-CALL  2  2?) 

(♦GOAL  (INCREASE  SALESMAN  2  2)) 

(♦GOAL  (SCHEDULE  2  TRAINING  -1))  ??? 

(Note  that  CASH  does  not  have  to  be  INCREASEd  In  this  line 
because  there  Is  already  a  sufficient  amount  to  support  the 
new  INCREASES.)  The  program  Immediately  notes  that  It  Is 
trying  to  schedule  In  negative  time,  and  terminates  the 
line. 

This  finishes  off  the  entire 
(♦GOAL  (INCREASE  SALES- PROBAB 1 L I TY ) ) 

Idea.  But  there  Is  still  another  way  for  the  program  to  try 
to  get  that  extra  SALE  It  Is  looking  for:  by  trying  to 
Increase  the  number  of  SALES-CALL ' s .  Thus, 

(♦GOAL  (INCREASE  SALE  1)) 


thesis,  and  for  making  final  debugging  recommendations  (see 
sect  Ion  4.4) . 
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(♦GOAL  (INCREASE  SALES-CALL  2  4)) 

(♦GOAL  (INCREASE  SALESMAN  2  4)) 

(♦GOAL  (SCHEDULE  2  TRAINING  1)) 

(♦GOAL  (INCREASE  TRAINING  2  1)) 

(♦GOAL  (INCREASE  HIRING  2  1)) 

(The  choice  of  time-slice  4  for  iNCREASIng  SALES-CALL  was 
not  arbitrary:  the  program  chooses  a  slice  where  It  thinks 
It  can  do  the  most  good.)  But  the  program  cannot  accomplish 
this  last  goal.  Why  not?  The  user  specifically  said  not  to 
hire  until  someone  quits.  The  program  then  checks  to  see 
If  HIRING  did  In  fact  occur.  Yes — one  time-slice  later. 
This  particular  set  of  circumstances  suggests  a  common 
timing  bug  In  the  manager’s  "flre-flghtlng"  approach  to 
problem  solvlng--no  action  was  taken  until  It  was  too  late 
for  It  to  do  any  good  (the  solution  Is  to  anticipate 
problems;  more  details  about  managers'  bugs  In  section  3). 
Since  this  bug  arises  from  so  specific  a  group  of  events, 
the  program  thinks  It  Isa  rather  probable  bug  and  gets 
ready  to  suggest  It  first.  It  then  checks  to  see  If  there 
are  any  other  ways  of  INCREASIng  the  number  of  SALE's. 
Since  there  are  not.  It  Is  finished  looking  for  bugs,  and  Is 
now  ready  to  suggest  the  bugs  It  knows. 

As  advertised,  the  first  bug  suggested 

to  the  user  Is: 
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--BAD  ‘SCHEDULE  FOR  HIRING: 
TOO  LATE 


DEPENDENT  ON 


QUIT; 


HIRING 


The  user  may  agree  that  this  Is  the  bug  (I  think  It  Is), 

or  ask  the  program  to  try  again.  The  next  bug  suggested 
I  s 

--BAD  SENSE  OF  PRIORITIES:  HIRING  AND  ADVERTISING 


Essentially,  the  program  suggests  that 
gotten  more  ADVERTISING  If  HIRING  did  not 
priority.  If  the  user  doesn’t  buy  this 
suggests  that  he  simply  blew  the  ‘SCHEDULE 


It  could  have 
have  higher 
,  the  program 
specification 


on  ADVERTISING: 


—BAD  ‘SCHEDULE  FOR  ADVERTISING:  NOT  ENOUGH 


'f  the  user  still  doesn't  like  what's  happening  (and 
since  the  program  has  suggested  all  of  the  bugs  It 
found),  the  program  decides  to  see  If  the  user  might  have 
ml s-spec I f led  or  completely  omitted  a  relevant  part  of 
his  model  (this  happens  more  often  than  you  might  think) 
It  then  uses  Its  access  to  WOBG  knowledge  to  suggest 
—MISSING  ‘ACTIVITY:  FACTORING 


(the  user  may  factor  accounts-rece l vabl e  to  provide 
Instant  cash)  and 

--MISSING  ‘ACTIVITY:  RESEARCH  AND  DEVELOPMENT 
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(the  user  may  Increase  the  probability  of  a  sale  by 
Improving  his  product). 

The  program  goes  out  of  the  debugging 
business  whenever  the  user  takes  a  suggestion,  or,  of 
course,  when  Its  bag  of  tricks  Is  exhausted.  The  user 
can  now  fix  his  model  or  change  his  expectations  and 
re-simulate.  Eventually,  this  process  of  simulation  and 
debugging  will  converge  to  a  model  that  the  user  Is 
confident  that  he  and  the  APS  both  understand 
suff Ic lentl y . 

In  this  section  I  have  tried  to  show 
a  complete  example  of  what  this  thesis  Is  about.  I  will 
now  go  Into  an  examination  of  the  foundations  of  this 
approach,  and  the  techniques  that  allow  Its 
Implementation.  I  begin  with  a  philosophical  discussion 
of  bugs  (yech). 


Page  35 


3  jjUfcS 


A  bug  is  something  that  prevents 
something  from  behaving  the  way  someone  expects  It  to. 
This  section  particularizes  the  notion  of  "bug"  to  a 
concept  which  Is  useful  for  this  research.  As  usual,  the 
program  only  knows  about  a  nar rowed-down  version  of 
"bug". 

We  will  be  Interested  here  only  in 
"understanding-bugs"--! .e.,  bugs  that  exist  only  in  the 
user's  understanding  of  the  system  he  wishes  to  model 
(cf.  Goldstein's  "semantic  bugs"  |5|).  This  Immediately 
removes  from  consideration  "parenthesis  errors"  and  other 
"syntactic  bugs"  (of  course,  trivial  syntax  bugs 
sometimes  arise  from  a  basic  misunderstanding).  Thus, 
there  will  be  no  Interest  whatsoever  in  finding  bugs  due 
to  MSL  errors.  In  fact,  no  attention  Is  given  to  bugs  of 
any  kind  that  arise  from  careless  expression  of  the 
user's  knowledge  In  the  modelling  formalism. 

The  kinds  of  bugs  with  which  the 
program  Is  concerned  are  those  that  seem  to  be  "Inherent" 
In  the  way  people  understand  (or  misunderstand)  systems. 
The  rest  of  this  section  will  be  devoted  to  an 
examination  of  bugs  that  occur  in  the  modelling  process 
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and  the  features  of  the  problem  domain  that  cause  them  to 
occur. 

3.1  Burs  id  models 
3.1.1  What  d 1 d  1  d£  wrong? 

What  happens  when  people  try  to  model 
systems?  They  usually  do  some  mumbling  and 
head-scratching  and  come  out  with  some  sort  of  expression 
of  their  Ideas.  In  this  research,  the  "expression"  Is 
required  to  be  rather  formal,  but  this  doesn't  matter 
much.  Next,  the  modeller  somehow  tests  his  .:odel  to  see 
how  It  performs  under  various  conditions  (just  as  my 
system  uses  simulation,  see  section  4.2).  Most  of  the 
time,  the  model  does  not  perform  as  the  modeller  expects 
It  to--"someth Ing  goes  wrong". 

Actually,  "something  went  wrong"  at 
deflne-ttme:  there  Is  something  In  the  definition  of  the 
model  which  Is  causing  the  unexpected  behavior.  I  have 
already  mentioned  the  hypothesis  that  the  user  has  a  good 
understanding  of  each  submodel .  (1)  Thus,  the  part  of 
the  model  definition  which  is  In  error  must  be  a 


(1)  The  notion  of  "submodel"  will  become  much  more  precise 
when  I  discuss  MSL  In  section  4.1. 


spec  1 f Icat Ion 
man  I f estat Ion  of 


of 


submodel 
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The 


Interaction. 

such  a  bug  varies  widely  with  the 
particular  bug  Involved#  and  tends  to  be  a  detailed 
matter  (l.e.#  highly  dependent  on  the  actual 

representation  formalism).  Therefore#  I  will  postpone 
(th  discussion  of  this  problem  until  after  I  have 
described  the  formalism  (4.4.2)#  and  go  on  to  an 
examination  of  the  "semantic  roots"  of  these  "interaction 
bugs". 

3.1.2  Interaction  bugs 

In  order  to  understand  the  Idea  of 
Interaction  between  submodels#  It  Is  helpful  to  view  the 
model  as  a  process  which  defines  the  action  of  the 
modelled  system.  Thus#  the  models  we  will  examine  here 
all  "do  something".  The  model  can  be  seen  as  a  system 
which  converts  some  sort  of  Input  resources  Into  some 
predefined  outputs.  (This  Is#  Ir  fact#  a  very  popular 
view  of  management  systems.)  For  the  model  to  "do" 
anything#  Its  submodels  must  Interact  with  each  other. 
That  Is#  the  Inputs  to  the  entire  model  are  actually 
Inputs  to  certain  submodels  which  convert  them  Into 
Intermediate  quantities  which  are  In  turn  Inputs  to  other 
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submodel s--and  so  on  until  the  desired  outputs  are 
obta Ined. 

Via  this  Interaction,  various 

dependencies  between  submodels  arise.  The  most  common 
Is  that  one  submodel  must  wait  for  the  completion  of 
another  before  It  can  begin  action.  (See  section  4.4  for 
a  detailed  account  of  different  kinds  of  Interaction 
between  MSL  submodels.)  Also,  submodels  often  share 

basic  resources,  giving  rise  to  conflicts  between 

submodel s . 

These  dependencies  and  conflicts 

between  submodels  provide  the  environment  for  the 
following  basic  "Interaction  bugs": 

(1)  Unexpected  conflict  arising  from  competition  for 
shared  resources 

(2)  Weak  performance  due  to  poor  perception  of 
time-phased  occurences 

(3)  Special  complexity  problems  arising  from  the 
concentration  of  (1)  and  (2)  In  "tight  systems"  bound 
by  higher-order  constraints 

Although  I  believe  that  these  bugs  have  considerable 
generality,  1  will  not  discuss  them  In  the  abstract. 
Instead,  I  will  move  Immediately  Into  the  domain  of 
management  systems  to  provide  a  framework  for  discussion. 
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systems 


The  bugs  catalogued  in  the  above 
subsection  arise  from  poor  understanding  of  complexity. 
This  "complexity"  Is  directly  inherited  by  the  models  from 
the  modelled  domain.  As  an  introduction  to  the  interaction 
complexity  of  organizations  in  the  world  of  business  (which 
form  the  basis  for  business  games,  the  "modelled  domain"  of 
this  thesis),  1  will  quote  in  full  an  Illustrative  passage 


from  Galbraith  I  4  I 


There  is  considerable  variation  in  the 
amount  of  interdependence  in  organizations.  The 
kinds  of  variation  can  be  Illustrated  by 
considering  a  large  research  .and.  development 
laboratory  employing  some  500  scientists  who  are 
pursuing  the  state-of-the-art.  Thus  we  have  a 
large  number  of  elements  and  high 
uncertainty.  However,  there  is  little  need  for 
communication.  All  the  projects  are  small  and  not 
directly  connected  to  other  projects.  Therefore  a 
schedule  delay  or  a  design  change  does  not 

directly  affect  other  design  groups.  The  only 
source  of  interdependence  is  that  the  design 
groups  share  the  same  pool  of  resources--men, 
facilities,  ideas,  and  money.  But  once  the 

initial  resource  allocations  are. made,  the  only 
necessary  communication  between  desirn  groups  is 
to  pass  on  new  Ideas  (Allen,  1969).  This  type  cf 
Interdependence  has  been  termed  as  PWl&a 

(Thompson,  1966,  Pp.  54-5).  . 

if  the  nature  of  the  projects 

Is  changed  from  250  small  independent  ones  to  two 
large  ones,  a  different  pattern  of  interdependence 
arises.  The  large  projects  will  require 
sequential  designs.  That  is,  a  device  is  first 
designed  to  determine  how  much  power  It  will 
require.  After  It  Is  complete,  then  the  design  of 
the  power  source  can  take  place.  Under  these 
conditions,  a  problem  encountered  in  the  design  of 
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the  device  v/i  1  1  directly  affect  the  group  working 
on  the  power  souce.  The  greater  the  number  of 
problems,  the  greater  the  amount  of  comunlcatlon 
that  must  take  place  to  jointly  resolve  problems. 

The  second  example  describes  a 
situation  which  Is  more  complex  and  requires 
greater  amounts  of  information  processing.  The 
second  example  has  all  the  problems  that  were 
described  in  the  first  example.  There  must  be 
budget  and  facilities  allocations  made  under 
conditions  of  uncertainty.  There  must  be  a  flow 
of  new  ideas  among  the  technical  specialties. 
But,  in  addition,  the  second  example  requires 
information  processing  and  decision  making  to 
regulate  the  schedule  of  sequential  activities. 
This  is  because  there  is  greater  interdependence 
in  the  second  example. 

The  interdependence  or 

interrelatedness  of  the  design  groups  can  be 
Increased  above  what  is  described  in  the  second 
example  by  the  degree  to  which  "design 
optimization"  is  pursued.  Optimization  means  that 
a  highly  efficient  device  is  desired  and  any 
change  in  the  design  of  one  of  the  components 
requires  redesign  of  some  others. 


This  can  be  Illustrated  by  an 
automobile  engine  and  body.  The  handling 
qualities  of  a  car  depend  on  the  weight  of 
the  engine.  The  engine  compartment  can  hold 
only  a  certain  size  of  engine  with  Its 
accessories.  The  drive  shaft  and 
differential  can  handle  only  a  limited 
amount  of  torque.  Changes  in  the  weight, 
size,  or  output  of  the  engine  may 
necessitate  changes  in  the  body  of  the 
automobile.  These  interrelations  and  many 
others  must  be  taken  into  account  In  the 
design  of  an  automobile. 

Actually,  in  the  case  of  a 
passenger  automobile  there  is  a  good  deal  of 
flexibility  with  regard  to  body-engine 
match.  The  engine  compartment  is  usually 
large,  the  parts  of  the  suspension  are 
easily  changed,  and  the  drive  shaft  probably 
has  plenty  of  excess  torque-carrying 
capabilty.  Engines  of  a  variety  of  shapes 
and  sizes  are  frequently  placed  in  the  same 
body.  But  this  need  not  be  the  case.  in 
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high-performance  automobiles/  the  size  of 
the  engine  compartment  Is  frequently  sharply 
constrained  by  aerodynamics  considerations. 
There  may  be  efforts  to  lighten  the  whole 
automobile  by  making  parts  of  the  drive 
system  and  body  as  light  as  possible;  given 
the  required  strengths.  In  such  a 
situation,  the  flexibility  in  the  size, 
shape  and  performance  of  the  engine  placed 
In  the  body  Is  sharply  reduced  or 
eliminated.  (Glennan,  1967) 

r» 

Thus  the  high  performance  .-auto  Is  a  highly 
Interrelated  system  while  the  passenger  car  is  a 
flexible,  loosely  coupled  system.  The  same  Is 
true  of  organizational  subunits  which  must  design 
these  systems.  Any  change  In  the  engine  design 
for  the  high  performance  car  must  be  communicated 
to  the  group  designing  the  body  so  that  an  optimal 
fit  is  still  achieved  after  the  change.  This  Is 
less  true  for  a  passenger  car.  Therefore,  the 
organization  designing  the  high  performance  car 
must  be  capable  of  handling  the  information  flows 
described  in  examples  one  and  two  for  budgets. 
Ideas,  and  schedules  and  also  those  for  all 
design-redesign  declsiors  deriving  from  the 
interrelated  design.  The  amount  of  information 
that  must  be  processed  increases  as  the  amount  of 
Interdependence  Increases. 


Each  of  Galbraith's  examples  Illustrates 
a  kind  of  interdependency  between  subunits  of  an 
organization.  The  first  kind,  pool ed  interdependency  . 
gives  rise  to  interaction  bug  (1)  of  the  previous 
subsection.  That  is,  when  resource  sharing  is  present,  there 
Is  liable  to  be  unexpected  conflict  betweer  subunits  trying 
to  use  the  same  resources  (These  are  the  PRIORITY  bugs  of 
the  example  In  section  2).  Galbraith  next  cites  an  example 
of  sequent  I  a  1  interdependency,  l.e.,  interaction  over  time 
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as  well  as  resources.  Again,  this  second  kind  of 
Interdependency  provides  an  environment  for  the  second  kind 
of  interaction  bug:  when  subunits  interact  over  time,  the 
modeller  is  liable  to  mls-estlmate  time-effects,  thus 
causing  degraded  performance  (these  are  the  SCHEDULE  bugs  of 
the  example  In  section  2).  Finally,  Galbraith  mentions 
h I gher-order  constra i nt  I nte rdependency .  (1)  Essentially, 
this  means  that  a  higher-order  objective,  shared  by  a  group 
of  subunits,  has  forced  a  need  for  greater  Interdependency 
among  the  subunits  of  the  group.  What  has  happened  Is  that 
in  the  new  "tighter"  system,  the  pooled  and  sequential 
Interdependency  has  been  spread  to  more  (sometimes  all) 
members  of  the  interactive  group.  This  kind  of 
Interdependency  has  a  direct  interpretation  In  the  WOBG 
which  will  be  discussed  in  the  next  subsection.  The  third 
kind  of  Interaction  bug  from  section  3.1.2  of  course  arises 
from  the  higher-order  constraint  environment.  (There  are  no 
examples  of  this  kind  of  bug  in  the  example  of  section  2; 
higher-order  constraints  were  deliberately  kept  out  for  the 


(1) 

I  think  that  the  introduction  of  the  "design 
optimization"  term  here  is  very  unfortunate.  The  point  is 
that  the  subunits  have  become  more  interactive  due  to  the 
presence  of  a  higher-order  constraint.  in  this  case,  the 
constraint  happens  to  be  that  the  units  must  interact  in 
order  to  achieve  an  optimal  design.  However,  in  the  next 
subsection  I  will  discuss  other  higher-order  constraints 
which  cause  the  same  increase  in  interaction. 
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sake  of  simplicity.  There  will  be  examples  of  this  kind  of 
bug  later  In  the  thesis.) 

These  three  types  of  Interdependency 
form  the  semantic  roots  of  the  bugs  considered  by  my 
program.  In  the  following  subsection  we  will  examine  the 
way  these  real  world  organizational  dependencies  are 
modelled  In  the  world  of  buslnes  games. 

3.3  Bugs  in  wo.bg  mQ.de.Is. 

Business  games  provide  a  laboratory  for 
teaching  managerial  decision-making.  Since  most  Important 
management  decisions  Involve  resolving  conflicts  (or 
possible  confl  lets.  1ri  the  case  of  planning)  arising  from 
subunit  Interdependency#  the  three  kinds  of 
Interdependencies  discussed  In  the  previous  section  are 
emphasized  In  many  business  games.  And#  of  course#  with  the 
three  Interdependencies  come  the  three  Interaction  bugs. 

Pooled  Interdependency  arises  from  a 
natural  sharing  of  resources  by  different  parts  of  the 
game-player's  "business".  The  business  game  contains  a 
very  well-defined  set  of  "resources"  (cash  #  salesmen# 
product lon-1 Ines.  etc.)  which  the  player  must  manipulate 
accord  ng  to  certain  specified  rules  of  play.  (1) 


The  basic 
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Idea  Is  to  accumulate  certain  resources  which  are  designated 
as  "assets".  There  are  a  variety  of  strategies  for 
accumulating  assets  (e.g.,  use  research,  do  some 
advertising,  learn  about  market  trends,  etc.).  The 
Important  point  for  us  Is  that  the  Implementation  of  aay 
strategy  requires  manipulation  of  various  subunits  of  the 
player's  "business".  These  subunits  share  the  pooled 
resource  of  gag h .  Since  g.g_s.h  Is  In  limited  supply,  an 
Interdependency  Is  set  up,  and  conflicts  arise.  Poor 
understanding  of  this  pooled  Interdependency  gives  rise  to 
section  3.1.2's  bug  type  (1):  "unexpected  conflict  arising 
from  competition  for  shared  resources." 

A  much  more  Interesting  aspect  of  the 
particular  game  I  have  selected  Is  the  sequential 
Interdependency  among  subunits.  First  of  all,  note  that 
some  of  the  activities  of  the  subunits  are  "long-term" 
(research  and  development,  training  sales  personnel, 
constructing  additional  production  capacity,  etc..),  while 
others  are  "short-term"  (advertising,  factoring  accounts 
receivable,  hiring,  etc.).  Second,  there  Is  considerable 
linkage  between  the  requirements  of  some  activities  and  the 


(1)  This  discussion  Is  based  on  the  actual  business  game 
presented  In  Appendix  A — It  might  be  a  good  Idea  to  glance 
over  the  description  of  the  game  to  give  yourself  the  flavor 
of  what's  going  on. 
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outputs"  of  others  (production  provides  units  to  sell, 
hiring  provides  employees  to  train,  etc.).  Finally,  the 
game  contains  a  rather  rich  "possibility  space"  for  any 
given  strategy  if  the  time-scale  is  long  enough.  That  is, 
there  are  a  variety  of  non-independent  ways  of  going  about 
achieving  a  given  task  over  time.  All  of  this  (plus  the 
addition  of  probabilistic  occurences  over  time)  adds  up  to  a 
complex  pattern  of  sequential  dependocles,  which  in  turn 
gives  rise  to  bug  (2),  "weak  performance  due  to  poor 
perception  of  time-phased  occurences". 

It  Is  characteristic  of  the  game  used 
here  (and  of  most  other  business  games)  that  the  pooled  and 
sequential  interdependencies  are  frequently  made  more 
intense  by  "higher-order  constraints".  These  constraints 
arise  from  the  activity  structure  of  the  game.  The  key 
factor  Is  that  various  activities  and  functions  of  the 
organization  depend  on  the  outputs  of  more  than  one  prior 
activity  (note  that  this  was  not  the  case  in  the  example  of 
section  2,  and  thus  this  problem  was  avoided).  I  can 
present  a  detailed  account  of  these  mutual  Interdependency 
relationships  only  after  I  discuss  the  way  the  game  is 
modelled  In  MSL  (  I  will  do  this  in  4.4).  For  now,  it  will 
suffice  to  say  that  two  kinds  of  higher-order  constraints 
are  distinguished:  the  kind  In  which  several  activities  (or. 


more  usually,  chains  of  activities)  must  combine  to  provide 

resources  for  another  activity,  and  the  kind  In  which  a 

> 

number  of  activities  can  combine  In  various  unstructured 
ways  to  achieve  a  functionally-determined  goal. 

This  section  has  been  devoted  to  filling 
In  rather  general  background  Information  about  the  kind  of 
bugs  the  program  knows  about  and  how  these  arise  naturally 
In  real  world  systems.  We  now  go  on  to  an  examination  of 
how  the  program  Incorporates  some  knowledge  about  these 
bugs,  and  how  It  goes  about  using  this  knowledge  to  debug 


mode  1 s . 
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4  hsm  Ihs.  program  works 

in  this  section  I  will  present  a  program 
which  finds  the  kind  of  interaction  hugs  discussed  above. 
An  example  of  program  operation  has  already  been  shown  in 
section  2.  From  this  example/  the  following  pattern  of 
program  operation  !s  evident:  the  program  starts  with  a 

model  represented  In  a  special  formal  language;  It  takes 
this  model  and  produces  a  simulation  of  it;  If  the  user 
finds  a  discrepancy  between  his  expectations  of  model 
performance  and  the  results  of  the  simulation,  he  presents 
the  program  with  the  goal  of  eliminating  the  discrepancy. 
The  program  then  attempts,  using  both  the  model  as 
originally  stated  by  the  user  and  the  results  of  the  model's 
simulation,  to  achieve  that  goal;  in  the  course  of  failing 
to  achieve  that  goal  (1)  ,  the  program  finds  features  of  the 
model  which  it  considers  to  be  unintended  causes  of  the 
fa  1 1 ure--bugs .  It  then  suggests  these  bugs  (in  order  of 
"likelihood")  to  the  user,  leaving  him  to  take  the  next  step 
(and  perhaps  re-initiate  the  process). 

This  section  considers  each  aspect  of 


(1)  The  program  shoul d  fail  to  achieve  almost  all  user 
goalsl  (The  "almost"  is  due  to  probabilistic 
considerations.)  Otherwise,  there  was  not  a  bug  and  the 
simulation  would  have  achieved  the  goal  in  the  first  place. 
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this  process  In  turn.  It  begins  (4.1)  with  an  examination 
of  the  model  specification  language,  providing  a  firm  basis 
for  understanding  what  the  program  does  and  does  not  know 
about  the  user's  model.  Next  (4.2),  It  describes  the 
simulation  of  the  model  and  the  way  the  results  of  the 
simulation  are  presented  to  the  debugger.  Continuing  along 
the  debugging  process,  section  4.3  deals  with  the  way  user 
goals  are  formed  and  the  way  In  which  the  system  handles 
goals.  Section  4.4  can  then  talk  about  how  the  program's 
deductive  mechanisms  pursue  goals  and  locate  bugs--the  real 
guts  of  the  debugging  problem.  Finally,  there  Is  a  short 
section  (4.5)  on  the  way  the  program  uses  real-world 
knowledge  in  the  debugging  process. 

into  the  heart  of  darkness... 

4 . 1  Ills,  model  spec  l  fm Icat  ion  1  anguage 

In  order  for  the  program  to  use  the 
s imul ate-and- i nves t Iga te  method  for  debugging  models,  the 
models  must  be  represented  in  a  form  that  Is  executable  (by 
the  simulate’)  and  a  form  that  is  examl nabl e  (by  the 
probl em-sol \  ing  routines).  The  model  specification 
language  (MS  L )  is  an  attempt  to  combine  these  two  necessary 
forms  In  a  s  ngle  language  (which  also  purports  to  be  fairly 
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user-oriented l ) . 

MSL  Is  a  set  of  simple  primitives  which 
can  be  used  to  describe  model s--espec i a  1 1 y  business  game 
models  (1)  .  An  MSL  specification  consists  of  an 
(unordered)  collection  of  the  three  basic  primitives 
♦ACTIVITY,  *EVENT,  and  *FUNCTION.  The  basic  primitives  are 
further  described  by  modifying  constructs.  The  model 
manipulates  user-defined  value/term  pairs  called  "resource 
variables"  (e.g.  (1000  CASH),  (SAM  SALESMAN),  etc.).  An 
example  of  MSL  specifications  appear  on  pages  17-18,  and  In 
Appendix  B.  This  section  contains  a  brief  description  of 
the  syntax  and  semantics  of  these  MSL  primitives. 

The  basic  MSL  construct  Is  the 
♦ACTIVITY.  The  concept  of  "activity"  used  here  is  precisely 
similar  to  the  usual  business  sense  of  the  word:  a 
well-defined  organizational  task  which  processes  some 
commodities  or  information  that  Is  used  by  the  organization 
(see  section  3.1.2;  see  also  the  VICE  |9|  for  its  Information 
on  activities).  An  *ACTIVITY  also  corresponds  to  a  submodel 
(2)  --that  thing  that  the  user  is  supposed  to  have  a  good 


(1)  No  claim  is  made  for  any  "completeness"  or  "sufficiency" 
of  this  set  of  primitives.  These  are  simply  constructs 
which  can  be  used  to  express  my  game  models. 

(2)  We  will  see  In  a  few  minutes  that  *EVENT’s  and 
♦FUNCTION’S  are  also  submodels. 
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grasp  of  (see  3. 1.1). The  ♦ACTIVITY  specification  looks  like 
(♦ACTIVITY  <  * ACT  I V I TY-name  >  <modlfiers>) 

(1) 

As  is  usually  the  case,  the  modifiers  are  the  rr  'St 
interesting  part  of  the  specification. 

One  modifier  which  Is  almost  always 
present  is  the  ♦PREREQUISITES  specification.  This 

construct  expresses  the  necessary  inputs  of  an  *ACTIVITY. 

The  ♦PREREQUISITES  specification 

contains  an  arbitrary  number  of 

(♦PRESENT  Cresouree  varlable>) 

forms  grouped  (implicitly)  by  OR  or  (explicitly)  by  AND. 
The  basic  interpretation  is  that  the  named  <resource 
variable)  must  be  present  (2)  for  the  *ACT1VITY  to  be 
initiated.  If  there  is  an  AND  specification,  then  (as  one 
would  expect)  all  of  the  "AND’ed"  resource  variables  must  be 
♦PRESENT.  Thus,  In 


(1)  I  will  use  the  following  notation:  "<"  and  ">"  are 
metalinguistic  brackets  which  surround  metalinguistic 
statements.  Everything  else  belongs  there. 

(2)  Clearly,  there  are  the  obvious  extensions 
’’♦MAY-BE-PRESENT",  "MUST-BE -PRES ENT'*,  etc.  I  have  not  found 
these  concepts  necessary  to  express  the  models  i  have  used. 
Therefore,  they  are  not  included  in  the  MSL,  even  though 
their  introduction  would  be  straightforward. 


(♦ACTIVITY  SALES-CALL 
(♦PREREQUISITES 
(AND 

(♦PRESENT  (1000  CASH)) 
(♦PRESENT  (1  UNIT)) 
^(♦PRESENT  (SOME  SALESMAN)) 


)  ) 


there  must  be  (1000  CASH),  (1  UNIT),  and 
SALES-CALL  to  be  Initiated. 

Some  further  comment 
quantification  mechanism  of  *PRESENT. 
SALESMAN)  represents  any  name  of  a 
model. That  Is, 


(SOME  SALESMAN)  for 

is  necessary  on  the 
The  "SOME"  In  (SOME 
SALESMAN  In  the 


(♦PRESENT  (SOME  SALESMAN)) 
will  be  satisfied  with 

(MARK  SALESMAN)  or 

(DON  SALESMAN)  or 

(STEVE  SALESMAN) 

Numerical  quantifications  carry  an  Implicit  "at  least" 
modifier.  That  Is, 


(♦PRESENT  (1000  CASH)) 
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will  be  satisfied  with 

(10000  CASH)  or 

(1000  CASH) 

but  not  (999  CASH) 

The  "at  least"  modifier  may  be  explicitly  stated,  or  may  be 
changed  to  AT-MOST,  as  In 

(♦PRESENT  (1000  CASH)  AT-LEAST) 

(♦PRESENT  (5  ERRORS)  AT-MOST) 

The  "outputs"  of  an  ‘ACTIVITY  are 
expressed  by  the  ‘OUTPUT  and  ‘REMOVE  constructs: 

(‘OUTPUT  <resource  varlable>) 

(‘REMOVE  <resource  var!able>) 

which  add  or  delete  the  named  resource  variable  from  the 
model's  resources. 

An  ‘ACTIVITY  construct  may  be  further 

described  by: 

(‘TAKES  <number>) 

to  Indicate  that  If  the  ‘ACTIVITY  Is  Initiated  In  time-slice 
n#  Its  outputs  do  not  become  available  until  time-slice 
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H±<nurr|hp  r  \  T, 

The  purpose  of  this  |s  of 

themode'"-  -  whIch  ;akeCa7Se't0a"ow 

amount  0f  nm„  _  .  an  appreciable 


modifier. 


time  to  be 


completed, 


Another 


important 


<*PRI0RI TV  <„umbe r> ) 
al  lows  the  user  to  ,ndlcat0 

resources  to  .activity',.  Th„s  ,f  '  °C3t'0n  °f 

vy-n6  for  th#  same  '  severaI  *«TIVITY't  are 

e  same  resource  rhD 

•PRIORITY  <number>  has  f,rst  '  „  °ne  W'th  the  '°West 

r  rst  crack  at  It  (l) 

♦SCHEDULE  spec  I f  trap  ■ 

to  slve  explicit  sched  l,  ''0"S  a"°W  the  user 

scheduling  Information  to  t^o  • 

order  to  limit  tho  simulator  in 

the  use  of  an  * ACTIVITY  Th. 

that  have  been  found  e  spec I f feat  Ions 

'  fou"d  useful  so  far  are 


(♦SCHEDULE  <number» 

to  Hmft  the  number  of  1 1, 
fn  any  t  lme-sl ice. 


fmes  an  ‘ACTIVITY  can  be 


schedu 1 ed 


(‘SCHEDULE  (ON  <‘EVENT-name» ) 
C°  a"°W  the  schedu,  Ing  of  an. ACT, V 


ITY  only  in  the 


same 


(1)  Again,  obvfou«;i»/  f-u?  ~  ~  * - -- — - 


tine-slice  as  the  occurence  of  the  named  *EVENT,  and 


(♦SCHEDULE  (EVERY  <number>)) 

to  limit  the  scheduling  of  the  *ACTIVITY  to  time-slice 
<numbe  r> / 2x<numbe  r> ,  3x<numbe r> ,e tc . 

The  above  modifiers,  along  with  the 
user's  ability  to  create  resource  variables  and  provide 
arbitrary  * ACT i V I TY  structures,  allow  enough  flexibility  to 
express  all  of  the  *ACTIVITY’s  necessary  to  model  the  game 
in  Appendix  A  (see  the  model  in  Appendix  B).  There  are, 
however,  other  kinds  of  submodels  to  be  considered. 

Another  basic  construct  (l.e., 
submodel -specif ier)  available  to  the  modeller  Is  the  *EVENT. 
This  Is  used  to  express  parts  of  the  model  which  are 
"outside  of  the  system" — beyond  the  organization's  direct 
control.  These  outside  influences  are  often  modelled  as 
probabilistic  occurences,  so  that  *EVENT's  are  usually 
associated  with  the  probabilistic  parts  of  the  model. 
♦EVENT  is  very  similar  to  *ACTIVITY  in  basic  syntax: 

(♦EVENT  <*EVENT-name>  <mod i f i e rs> ) 

but  the  modifiers  are  somewhat  different. 

Instead  of  the  *PREREQU I S I TES 
specification,  a  ^CONDITIONS  list  Is  stated: 


- -  I.* 
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(♦CONDITIONS  <boo!ean  expression)) 


That  Is,  the  simulator  expects  the  body  of  a  ‘CONDITIONS 
list  to  evaluate  to  "true"  or  "false".  Usually,  the  body 
contains  some  combination  (perhaps  related  by  AMD  or  OR)  of 
♦FUNCTION  names  (1)  (see  below).  The  Intent  is  that  the 
♦EVENT  may  not  be  Initiated  unless  the  <boolean  expression) 
evaluates  to  "true". 


Usually  *EVENT's  affect  particular 
♦ACTIVITY' s. The  suscteptlble  *ACTIVITY's  and  the  actions  to 
be  taken  by  the  *EVENT  are  expressed  within  the  *EVENT  by 
the  *ACT I V I T I ES  modifier: 

(♦ACTIVITIES  ( <1  1st  of  *ACT I V I TY-names> )  <actlons>) 

If  an  *EVENT  contains  an  * ACT  I V  I T I E  S  construct,  it  can  be 
Initiated  only  In  a  time-slice  In  which  at  least  one  of  the 
named  *ACTIVITY's  Is  scheduled. 

One  rather  unusual  <action>  which  can  be 
taken  by  an  *EVENT  Is 


(1)  These  ‘FUNCTION'S  usually  express  a  probability  with 
which  the  *EVENT  occurs  In  a  given  time-slice.  The 
simulator  sets  up  a  probabilistic  event  (no  confusion, 
please!)  on  the  related  sample  space  to  express  the 
♦FUNCTION.  It  then  calls  a  random  number  generator.  If  the 
value  returned  by  the  RNG  falls  within  the  defined  event, the 
simulator  assigns  "true"  to  the  value  of  that  ‘FUNCTION. 


Hi  I J !! .  M u  W II  aU,.HJ*UH  I , 
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(♦CANCEL) 


This  means  that  the  Interrupted  *ACTIVITY  has  been 
permanently  disrupted  and  Is  to  be  unscheduled.  (Of 
course.  It  can  be  rescheduled  later.)  In  all  other 
respects,  ‘EVENT'S  are  treated  just  like  ‘ACTIVITY'S. 

The  final  basic  construct  In  MSL  Is 
♦FUNCTION.  It  expresses  a  functional  relationship  between 
variables  In  the  model,  and.  In  general,  accounts  for 
Information  flow  within  the  model.  It  Is  thus  slightly 
different  In  spirit  from  the  resource-handling  ‘ACTIVITY'S 
and  ‘EVENT ' s .  Nonetheless,  it  shares  submodel  status  (1)  , 
and  Is  similar  In  syntax  to  the  other  two  basic  constructs: 


(‘FUNCTION  <*FUNCTI 0N-name>  <modlflers>) 

‘FUNCTION'S  are  not  "scheduled";  rather,  they  are  Invoked  by 
being  mentioned  In  other  constructs  (just  as  In  programml ng 
language  function  calls).  Thus,  whenever  SALES-PROBAB I L t TY 
(see  section  2)  appears  In  the  model  (except  In  the 
♦FUNCTION  definition,  of  course),  the  ‘FUNCTION 


(1)  It  is  important  to  recognize  that  information-handling 
activities  are  submodels  at  the  same  level  as  other 
organizational  activities.  Forrester  stresses  this  point 
In  13 |,  and  seems  to  use  the  homogeneity  of  basic  submodels 
successfully.  Of  course,  the  uniform  submodel  constructs 
also  lead  to  a  gain  In  mode lllng  efficiency  and  a  1  es sen l n g 
of  the  cognitive  load  of  the  MSL  user. 
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SALES-PROBABILITY  will  be  Invoked. 

The  analogous  construct  to 

♦PREREQUISITES  and  ^CONDITIONS  In  *FUNCTI0N  Is 

(♦ARGUMENTS  <argumentl>  <argument2>  . ..) 

which  behaves  like  the  usual  argument-list  In  programming 
language  functions.  Missing  arguments  cause  an  "error" 
which  stops  the  simulation  (1)  . 

The  analogy  to  *0UTPUT  Is 
(♦RETURN  <express l on> ) 

where  <express!on>  can  be  a  combination  of  *FUNCTI0N  names 
and  the  special  function-representing  constructs 

(♦TABLE  ( <*ARGUMENT-name>  <*RESULT-name> ) 

<a rgument/ result  palrs>) 

(♦SUM-UP  ( <va r I abl e  range>)  <llrear  factors>) 

This  is  about  all  there  Is  to  the  MSL. 
The  semantics  of  *ACTIVlTY's  and  *EVENT's  are  developed  a 
bit  further  In  the  n<;xt  section.  ♦FUNCTION'S  are  dealt  with 
In  4. 4. 2.1.  However,  no  really  detailed  descriptions  are 
presented  anywhere.  There  is  little  point  in  it.  The  only 

(1)  This  Is,  of  course,  the  kind  of  bug  we're  not  Interested 
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purpose  of  presenting  MSL  is  to  allow  the  reader  to 
understand  the  examples  and  judge  what  the  program  does  and 
does  not  know  about  a  particular  model. 

Almost  all  of  what  the  program  knows 
about  any  given  model  is  in  the  MSL  specification.  (It 
knows  a  fev;  other  things  discussed  in  4.5.)  MSL  can  be 
simple  because  the  models  considered  are  quite  simple.  As 
the  models  become  more  complex  we  expect  (by  conservation  of 
complexity)  that  MSL  will  become  more  complex.  The  hope  is 
that  MSL  contains  something  general  enough  to  handle  some 
kinds  of  additional  model  complexity  without  additional 
language  complexity.  This  "something"  is  the  basic 
philosophy  of  submodel  structuring  which  is  reflected  in  the 
MSL.  Thus,  I  have  tried  to  emphasize  this  basic  structure 
rather  the  details.  In  the  next  section  we  follow  the 
course  of  the  program's  debugging  process  and  examine  the 
simulation  of  MSL  models. 

4 . 2  Simulation  as  a  way  of  do i ng  t h i ngs 

Simulation  is  a  technique  for  observing 
the  behavior  pf  models.  In  the  absence  of  analytical  and 
other  "high-level"  tools  (like  educated  guesses),  simulation 
Is  the  only  way  to  find  out  wha  a  model  "does"  in  any  given 
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situation.  In  the  model -debugg l ng  system  presented  In  this 
thesis#  the  simulator  sets  up  the  basic  feedback  mechanism 

between  user  and  APS. 

At  the  very  least#  any  APS  should 
provide  a  facility  for  checking  out  model  behavior  with 
simulation.  That  Is#  the  user  formulates  his  model#  tests 
It  via  simulation#  changes  it  If  he  doesn't  like  what  he 
sees#  and  reslnulates.  For  reasons  discussed  in  the 
Introductory  section#  It  Is  necessary  to  go  a  step  further. 
The  program  described  here  attempts  to  aid  the  user  In 
discovering  why  the  model  does  not  perform  as  he  expects  it 
to  . 

Therefore#  this  section  will  concentrate 
on  simulation  as  a  way  of  Initiating  Lbe  debugging  process. 
This  emphasis  Ignores  very  important  Issues  of  presenting 
simulation  results  to  the  user.  In  fact#  It  completely 
downplays  the  Importance  of  the  simulator  Itself# 
concentrating  only  on  the  Interaction  of  the  simulator  and 
the  deductive  mechanisms  of  the  debugging  program.  Thus# 
In  this  section  I  will  proceed  to  finesse  the  simulator  and 
move  on  to  the  more  relevant  problems  of  representing  the 
knowledge  gained  by  the  simulation  In  such  a  way  that  It  can 
be  used  by  the  debugger. 


4.2.1  Hie.  simulator  finessed 


In  this  section  I  will  very  briefly 
describe  the  simulation  scheme  used  In  the  program.  The 
whole  simulation  philosophy  presented  here  Is  kind  of 
strange  as  viewed  from  the  standpoint  of  "normal"  simulation 
programs.  This  Is  due  to  the  presence  of  two  major  design 
criteria  not  usually  found  In  the  area  of  simulation 
programming: 


(1)  Adherence  to  the  "user  only  knows  local  submodel 
Information"  canon  ennunclated  earlier  (sections  1.3.1 
and  3.1.1) 

(2)  The  goal  of  representing  knowledge  found  by  the 
simulation  In  such  a  way  that  It  can  be  used  by  the 
debugge  r 

The  first  criterion  gives  rise  to  those  funny  MSL  constructs 
which  mysteriously  appeared  in  the  previous  discussion, 
it  also  motivates  the  style  of  simulation  described  In  the 
rest  of  this  section.  The  second  criterion  determines  the 
actual  implementation  of  the  algorithm,  and  is  dealt  with  In 
the  following  subsection. 


in  MSL,  the  Information  pertaining  to  a 
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particular  submodel  Is  found  only  In  that  submodel.  The 
kind  of  "Information"  varies  from  submodel  to  submodel  (as 
described  In  4.1),  but  basically,  the  following 
specifications  are  necessary: 

--resources  needed  by  the  submodel 

—  resources  produced  by  the  submodel,  and  the  length  of 
time  necessary  to  produce  them 

--explicit  policy  for  the  conditions  under  which  the 
submodel  should  be  activated 

The  basic  operation  of  the  simulator  is 
then  straightforward. Each  submodel  Is  activated  when  Its 
(user-specified)  explicit  pre-conditions  are  satisfied, 
provided  that  all  of  its  necessary  resources  are  available, 
if  the  user  does  not  specify  pre-conditions  (via  *SCHEDULE 
and  *C0ND  ITiONS  — see  4.1),  the  submodel  is  activated 
*ihgneYe,r-  lts  necessary  resources  are  available  (subject  to 
♦PRIORITY  restrictions,  of  course).  When  the  time 
(specified  by  *TAKES )  for  submodel  activity  has  elapsed,  the 
output  resources  of  the  submodel  (if  any)  be -ome  available 
to  the  whole  model.  This  process  of  cycling  through 
submodels  activating  "ready"  ones,  continuing  "running" 
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ones,  cleaning  up  finished  ones,  and  augmenting  and 
depleting  resources  all  along  continues  for  the  duration  of 
the  user-specified  run-length. 

Mow  anyone  who  has  ever  glanced  at  the 
guts  of  a  simulator  knows  that  I  have  just  finessed 
inumerable  details  (as  well  as  a  few  Important  Points).  The 
algorithm  used  In  the  program  is  actually  a  bit  more 
sophisticated  and  a  great  deal  hairier  than  the  one 
"described"  above.  For  example,  I  have  not  even  mentioned 
the  rathe  r  ticklish  problem  of  handling  probabilistic 
occurences  In  this  context,  nor  the  design  decisions  for 
priority-scheduling  of  already-running  submodels.  !  am 
deliberately  sluffing  the  details  here  because  the  simulator 
itself  is  not  very  important  to  the  thesis  as  a  whole.  It 
is  its  output,  the  SIMULATION-HISTORY  context,  that  I  wish 
to  emphasize  here. 


4.2.2  Simulation  h 1 storv  SIMULATION-HISTORY 

The  form  of  the  output  of  a  simulation 
program  is  always  a  key  factor  in  Its  usefulness.  In  the 
debugging  system  presented  here,  it  Is  an  essential  link 
between  the  model  and  the  deductive  mechanisms  of  the 
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debugger.  As  discussed  above,  much  of  the  task  of  the 
simulator  is  to  present  the  knowledge  gained  by  simulating 
the  model  In  a  form  that  can  be  used  by  the  rest  of  the 
program.  This  is  of  course  the  old  artificial  intelligence 
task  of  representing  knowledge  in  a  form  that  can  be  used  by 
procedural  deductive  mechanisms. 

The  style  of  representation  I  have 
chosen  for  the  simulation  knowledge  is  the  slmulai-  inn 
history.  Now  this  is  hardly  startl lng--simulat ion 
histories  are  frequently  used  to  describe  the  behavior  of 
systems.  But  here  I  wish  to  extend  the  concept  somewhat. 
In  my  program,  the  simulator  constructs  a  simulation  history 
(called  SIMULATION-HISTORY)  which  then  becomes  the 
OTOt?lenr.SO.I,Y  inK  envl  ronment  of  the  debugger.  By  this  I 
mean  that  from  the  point  of  view  of  the  deductive  mechanisms 
In  the  debugger,  the  "world"  is  a  simulation  history;  l.e., 
a  sequence  of  facts  about  the  model  which  are  true  at 
various  times  determined  by  the  simulation.  The  debugger 
lives  inside  this  simulation  history.  The  things  that  it 
knows  about  the  "world"--the  kinds  of  knowledge  found,  the 
way  events  are  related,  etc.--  are  the  facts  and  rules  of 
the  simulation  history  world  (1)  .  In  thinking  about  the 


(1)  Except  for,  as  we  shall  see  later,  the  facts  it  knows 
about  the  'real  world"  of  business  games. 
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debugger.  It  Is  well  to  keep  In  mind  that  It  Is  a  citizen  of 
the  simulation  history  world. 

Well  then,  let's  go  slumming  and  look 
around  the  simulation  history  world  ourselves  for  a  few 
rollicking  moments.  Consider  some  set  of  observational 
variables  on  a  simulation  model.  Then  a  simulation  history 
can  be  thought  of  as  a  recording  of  the  "values"  of  these 
variables  at  various  Instants  of  s  Imul  at  lon-t  Irre .  The 
Interesting  questions  are  what  observational  variables 
should  be  used  and  how  the  record  should  be  organized.  We 
will  see  that  these  questions  are  Important  with  respect  to 
the  usefulness  of  the  simulator  to  the  debugger. 

For  the  simulation  to  progress  from  one 
time  Instant  to  the  next,  the  simulator  must  have  a  record 
of  the  state  of  the  simulation.  The  simulation  state  of 
these  simple  MSL  models  consists  of  four  main  pieces  of 
Information : 

(1)  the  value  of  each  "resource  variable"  (see  4.1)  at 
the  end  of  each  time-slice  (1) 


(2)  a  record  of  the  ‘ACTIVITY'S  which  were  Initiated  In 
the  tlme-sl Ice 


(1)  A  time-slice  Is  one  ker-chunk  of  the  simulator 
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(3)  a  record  of  the  *EVENT's  which  occur  and  the 
♦ACTIVITY'S  they  affect 

(4)  an  indication  of  the  stage  of  completion  of  each 
"running"  (i.e.,  previously  initiated  and  not  yet 
complete)  *ACTiVITY  and  *EVENT 

Therefore,  the  simulator  needs  these  four  pieces  of 
information  at  the  end  of  each  time-slice  in  order  to  go  on 
to  the  next  time-slice. 


But  what  does  this  have  to  do  with  the 
"observational  variables"  for  the  simulation  history?  First, 
remember  that  the  "observer"  in  this  case  Is  the  deductive 
mechanism  of  the  debugger.  Now,  harking  back  to  ail  that 
was  said  In  sections  1  and  2  about  debugging  by 
problem-solving,  we  can  see  that  the  debugger  is  usually  in 
the  position  of  trying  to  change  the  course  of  the 
simulation  in  some  way  (to  cause  some  desired  outcome  which 
causes  another  desired  outcome,  etc...  which  eventually 
causes  the  user's  desired  outcome).  In  order  to  decide 
whether  it  can  make  the  change  (1)  it  must  know  something 


(1)  Of  course.  It  must  also  decide  whether  the  user  wants 
the  change  to  be  made.  This  part  of  the  problem  is 
discussed  In  4.4.2. 
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about  the  simulation.  Specifically,  It  must  know  the  state 
of  the  simulation  and  ways  to  change  that  state  (1)  .  The 
ways  to  change  the  state  are  encoded  In  procedural  deductive 
mechanisms  to  be  described  later  (4.4.1).  The  state  of  the 
simulation  can  be  provided  by  the  simulation  history. 
Therefore,  the  observational  variables  for  the  simulation 
history  are  just  the  state  variables  discussed  above  (2)  . 

Well,  since  the  simulator  needs  the 
values  of  the  state  variables  at  the  end  of  each  time-slice, 
the  program  need  only  keep  track  of  these  values  In  some 
useful  fashion.  The  problem  now  becomes  one  of  organizing 
the  simulation  history.  In  order  ot  think  about  such  an 
organization,  we  can  look  back  to  section  2  and  remember  a 
bit  more  about  what  the  deductive  mechanisms  do  with  the 
simulation  history. 

The  deductive  mechanisms  usually  find 
themselves  playing  around  In  their  little  simulation  history 
world  In  two  ways: 

(1)  examining  a  single  time-slice  to  see  whether  a 
change  can  be  made  at  that  time 


(1)  This  Is  Its  "world  knowledge"  of  the  simulation  history 
wo  r  1  d . 

(2)  A  schematic  representation  of  these  state  variables  as 
they  appear  In  the  simulation  history  Is  found  on  pp.  21-23. 
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(2)  examining  a  large  segment  of  the  simulation  to 
choose  a  likely  time-slice  for  scheduling  something 
new,  to  follow  the  course  of  an  ^ACTIVITY  or  ♦EVENT,  to 
pursue  the  consequences  of  a  proposed  change,  or  (as  we 
shall  see  later  In  this  section)  to  handle  higher-order 
constra Ints 

What  we  need  Is  a  good  representation  for  facile  handling  of 
time-slices  and  (usually  contiguous)  groups  of  time-slices. 
The  representation  should  also  allow  ease  In  the  building-up 
and  manipulation  of  the  whole  history. 

Such  a  representation  is  the  Conniver 
C9.n text  |20|.  The  simulation  history  is  implemented  as  a 
Conniver  captext  with  the  unlikely  moniker  of 
SIMULATION-HISTORY.  Each  time-slice  Is  a  layer  |20|  of  the 
C9n texA «  This  Conniver  Implementation  implies  the  following 
relation  between  time-slices:  the  simulator  "grows" 
SIMULATION-HISTORY  by  adding  on  new  time-slices;  changes 
made  to  the  data  in  a  new  time-slice  are  invisible  to 
earlier  time-slices,  however,  the  status  of  any  datum  can  be 
determined  in  any  time-slice.  This  certainly  gives  us  the 
record  of  the  simulatior.  history  that  we  want.  Conniver 
also  allows  any  part  of  the  con  text  to  be  regarded  as  a 
separate  context .  The  importance  of  this  Is  that  the 
C9ntext  can  then  be  used  as  the  database,  or,  more 


■■■  —  . . •" . * - **— - - - ■ -  .  I-***,.**. . - - - - - 
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prec!se1y/  as  the  working  environment  for  some  set  of 
programs.  That  Is,  the  programs  In  a  given  context  work 
only  with  that  £fini£JLt  as  a  knowledge  base.  Thus,  we  can 
see  that  the  deductive  mechanisms  of  the  debugger  can  "live 
Inside"  the  simulation  history  by  simply  using 
SIMULATION-HISTORY  as  their  £p£it;ext.  Furthermore,  the 
deductive  mechanisms  can  live  Inside  any  part  of  the 
simulation  history  which  they  must  examine.  Their  world  can 
be  a  single  time-slice  or  a  large,  program-edited  piece  of 
the  history. 

We  will  see  that  this  ability  to  live 
Inside  arbitrary  pieces  of  SIMULATION-HISTORY  Is  a  key 
requlstlte  for  the  deductive  mechanisms  of  the  debugger. 
For  the  deductive  mechanisms  to  work,  they  must  apply  their 
procedural ly-embedded  knowledge  of  how  to  change  the  course 
of  the  simulation  to  carefully  chosen  parts  of  the 
simulation.  This  Is  why  the  simulation  history  and  Its 
Implementation  as  SIMULATION-HISTORY  form  such  an  Important 
part  of  the  program.  In  the  next  section,  we  will  find  that 
the  SIMULATION-HISTORY  representation  gains  further 
Importance  when  the  debugger  generates  hypothetical  states 
of  the  simulation. 


4.3  Qpfl]  §  and  env  i  ronment  <; 
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Throughout  the  thesis  I  have  been  using 
the  word  "goal"  to  describe  a  variety  of  phenomena.  I  have 
spoken  of  user  goals,  system  goals,  and  submodel  goals.  In 
section  2  I  introduced  another  construct  containing  the  word 
"goa 1 " : 

( *G0AL  <st range  words>  <numbers>  Clots  of  parentheses)) 

which  purported  to  represent  the  various  other  kinds  of 
goals  to  the  program.  In  this  section  I  will  discuss  what 
these  parenthetical  thingees  mean  to  the  program.  In  the 
next  section  I  will  talk  about  how  they  are  created  and 
manipulated.  Here  I  describe  only  goals  *G0AL  1  s  i  .e  . , 
the  common  structural  aspects  of  *G0AL's. 

A  goal  expresses  a  desired  state.  In  a 
debugging  context  this  desired  state  is  almost  always 
inconsistent  with  the  actual  state.  This  is  because  the 
user  has  found  a  discrepancy  between  reality  and  expectation 
and  has  thought  of  a  desired  state  In  which  the  discrepancy 
is  resolved.  Thus,  the  desired  state,  reflecting  the  fixed 
discrepancy.  Is  inconsistent  with  the  actual  state.  In  the 
program  presented  here,  the  user  can  ask  the  program  to 
produce  this  desired  state  (given  the  model  and  the 
simulation  history--see  section  2).  (1)  The  request  is  made 


(1)  As  discussed  elsewhere,  the  program  fails  In  its  attempt 


via  a  *GOAL  statement: 


(♦GOAL  <ach!eve  desired  state>) 

What  does  it  mean  to  "achieve  the 
desired  state"?  The  user  Is  asking  the  program  to  change 
the  course  of  the  simulation.  The  program  goes  about  this 
by  first  creating  a  hypothetical  simulation  state 
(time-slice)  which  includes  the  desired  state.  Then  It 
attempts  to  make  the  rest  of  the  simulation  history  (i.e., 
the  previous  time-slices)  consistent  with  the  new 
hypothetical  time-slice.  (1)  This  Is  done  by  the  creation 
of  a  new  *G0AL 


(♦GOAL  <make  previous  time-slice  consistent  with  new  one>) 


This  new  ♦GOAL  Is  clearly  of  the  form 


(♦GOAL  <ach!eve  desired  state>) 


and  can  thus  be  handled  exactly  like  the  user  goal.  The 
program  can  thus  recurse  merrily  along  until  it  cannot 
achieve  a  desired  state--!. e.,  until  it  falls. 

Now  then,  let's  take  a  closer  look  at 


to  produce  the  desired  state,  but  this  Is  not 
the  discussion  of  this  section. 


Important  to 


' s  "work  backwards"  methodology  Is  due  to  the 
debugging  philosophy  of  tracing  a  bug  from  its  manifestation 
back  to  Its  cause. 
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this  process.  Each  ♦  GOAL  requests  a  specific  change  to  a 
specific  local  environment  (the  time-slice).  Thus,  each 
♦GOAL  is  attempted  in  the  context  of  a  local  constraint 
environment  represented  by  a  single  time-slice  of  the 
simulation  history.  (1)  If  the  *G0AL  is  achieved.  It  will 
define  a  new  environment  which  is  inconsistent  with  the  old 
time-slice  (because  of  the  changes  wrought  by  achieving  the 
♦GOAL).  This  new  environment  is  then  consistent  with  the 
user's  desired  state,  but  inconsistent  with  the  old 
simulation  history.  The  program  will  then  use  this  new 
local  environment  as  a  basis  for  defining  the  next  desired 
state  along  the  line  toward  making  the  whole  simulation 
history  consistent  with  the  user's  desired  state.  The 
program  Is,  In  effect,  constructing  a  new  hypothetical 
simulation  history  which  results  in  the  user's  desired 
state.  (2) 

Thus,  environments  are  intimately 
related  to  the  semantics  of  *GOAL's.  Each  *GOAL  Is 
constrained  by  a  pre-spec  I f i ed  part  of  the  simulation 


(1)  Not  quite.  As  we  shall  see  in  a  second,  multiple  goals 
are  achieved  with  respect  to  a  local  constraint  environment 
consisting  of  several  time-slices. 

(2)  The  next  section  deals  with  the  problem  of  how  the 
program  constructs  this  simulation  without  destroying  the 
original  intent  of  the  model.  Specifically,  section  4. 4. 2.1 
gives  a  better  picture  of  what  is  "constraining"  about  a 
"local  constraint  environment". 
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env I ronment --that  part  which  u 

which  It  IS  supposed  to  Change.  The 

achievement  of  a  *rnAi 

r  a  *GOAL  c<>n  therefoi 

transformat  Ion: 


're  be  seen  as  a 


*GOAL 


\^\a\  £nv/iron^e>iif 


new  e^vAA^iwit 


This  transformation  Is  a  local  phenomenon.  However  the 

C  feCtS  °f  the  transformatI^  are  non-local.  The  *GOAL  has 
Perturbed  the  local  environs  and  made  It  Inconsistent 

t  e  global  environment.  Since  the  eventual  goal  of  the 
Pro  lem  solver  Is  to  create  a  consistent  simulation  history 

"  reSUUS  —  -te.  the  global 

environment  must  ho 

be  made  consistent  wlth  thls  new 

Inconsistent  piece: 


m'fonMr  <kW  sWe 
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In  order  to  make  the  global  environment 
consistent,  the  program  must  trace  down  the  effects  of 
changing  that  local  piece.  In  other  words.  It  must  examine 
the  way  .hat  local  piece  Interacts  with  other  pieces  of  the 
global  environment: 


But  this  Is  exactly  what  we  want.  The  user  is  Incapable  of 
following  the  Interactions  of  the  model.  If  the  program  is 
to  help  the  user  find  the  "interaction  bugs"  thus  created, 
it  must  have  some  mechanism  for  tracing  interactions.  This 
mechanism  is  the  problem-solver. 

The  problem-solver  uses  a  *GOAL  to 
express  a  global  environment  perturbation.  It  then  uses  the 
deductive  mechanisms  described  in  the  next  section  to  follow 
that  perturbation  throughout  the  local  environment,  the 
local  change  at  each  point  being  determined  by  a  *GOAL. 
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When  the  program  comes  to  a  point  where  the  perturbation 
cannot  fce  continued  (l.e.,  where  a  *G0AL  falls).  It  has,  in 
effect,  discovered  a  part  of  the  environment  which  cannot  be 
f C* rm  to  the  user's  desired  environment.  It  has 
traced  the  Interaction  path  to  Its  roots— It  has  bracketed 
the  bug  location  between  the  user's  desired  simulation  state 
and  the  user's  desired  constraint  which  gave  rise  to  the 
Interaction  (see  4,4.3). 

Thus,  *GOAL ' s  are  the  vehicle  for 
exploring  the  interactive  behavior  of  the  model.  As  we  have 
seen  above,  the  use  of  *G0AL's  In  this  way  requires 
sophisticated  manipulations  of  local  environments.  In 
order  to  tie  down  some  of  the  concepts  discussed  In  the 
previous  paragraphs,  I  will  now  discuss  some  of  the  problems 
the  program  faces  with  respect  to  this  environment-handling. 

First,  each  *GOAL  must  be  achieved  with 
respect  to  a  local  environment.  That  Is,  the  *GOAL  must 
only  "see"  the  constraints  of  a  local  environment  (not  the 
whole  thing)  (1)  ,  and  must  directly  affect  only  that  local 
environment.  Otherwise,  the  distinction  between  local  and 
Interactive  behavior  Is  lost— there  Is  no  such  thing  as  a 


(1)  This  Is  due  first  to  the  nature  of  the  problem-solving 
process--  set  up  a  local  environment  and  then  make  the  next 
local  environment  up  the  line  consistent  with  It"— and 
second  to  the  debugging  philosophy  espoused  In  4. 4. 2.1. 
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"perturbation". 

Fortunately,  the  environment  to  be 
examined  >s  the  SIMULATION-HISTORY  context.  We  will  see  In 
4. 4. 2.1  that  the  required  local  environment  Is  (usually) 
just  a  TIME-SLICE  of  the  SIMULATION-HISTORY.  The  *GOAL  can 
thus  be  made  to  "see"  only  a  local  environment  by  making  the 
required  TIME-SLICE  Its  working  environment  (as  In  4.2)  (1) 
The  £.g.ntm  structure  makes  the  relation  between 

TIME-SLICE’s  evident  (i.e.,  because  each  Is  a  Conniver 
liYfiX)/  so  that  the  distinction  between  local  and 
Interactive  constraints  Is  explicit  In  the  built-in 
(Conniver)  semantics  of  SIMULATION-HISTORY. 

Now  the  *G0AL  must  also  be  made  to 
only  a  loca1  environment  If  the  semantics  discussed 
earlier  are  to  be  preserved.  It  would  seem  that  this  is 
just  as  easy:  simply  keep  the  TIME-SLICE  In  question  as  the 
♦GOAL’S  working  environment,  and  all  changes  will  explicitly 
have  the  required  locality.  However,  there  is  a 
complicating  factor  found  In  all  searching  problem-solvers: 
the  problem-solver  must  make  provisions  for  discarding  an 
old  line  of  attack  and  beginning  a  new  one.  This  is  the  old 
problem  of  backup  which  has  been  discussed  extensively  in 


s. 


ii?iTh,S  l?n't  qulte  so  simple  for  multiple  *GOAL ' 
we'll  see  In  a  second. 


as 
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I  7 1  and  |19|. 

The  backup  problem  Is  germane  to  the 
debugging  process  because  the  debugger  usually  attempts  to 
find  all  possible  causes  of  a  particular  discrepancy  (In  the 
hope  that  one  of  them  Is  the  actual  bug).  Thus#  It  will 
follow  down  one  line  of  attack#  fall#  and  try  another.  It 
must  therefore  be  ready  to  erase  the  consequences  of  the 
line  to  be  discarded.  But  this  Is  a  particularly  hard 
problem  for  the  debugger.  Here#  the  tracks  leading  to 
failures  are  the  key  to  the  rest  of  the  process.  They 
cannot  be  simple  "erased"#  but  must  be  preserved  In  some 
form  which  the  program  can  use  to  suggest  bugs  and  to 
explain  Its  actions  to  the  user  see  4.4.3). 

Furthermore#  while  the  effects  of  each 
*G0AL  must  be  restlcted  to  a  local  environmet#  the  effects 
of  al  1  the  *GOAL's  must  create  a  new  consistent  environment 
(1)  .  Thus#  the  program  must  maintain  some  new  environment 
which  localizes  the  effects  of  the  *GOAL's#  allows  a 
controlled  backup  with  preservation  of  the  backed-over 
Information#  and  which  forces  consistency  of  all  affected 
environments.  Certainly#  SIMULATION-HISTORY  will  not  do. 

But  something  like  It  will.  The  program 
again  uses  a  1 avered-context  structure.  In  each  layer  It 


(1)  They  must#  In  fact#  create  a  new  simulation  history 
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records  the  changes  made  by  a  *G0AL  to  the  particular 
TIME-SLICE  Involved.  It  then  appends  this  new  1  a ve r  to 
SIMULATION-HISTORY  and  uses  this  new  augmented  context  as 
the  working  environment  of  the  debugger.  Now,  remembering 
the  little  discussion  of  context  semantics  in  4.2  (or, 
referring  to  |20|),  we  see  that  this  causes  the  following 
effects : 

(1)  The  effects  of  a  *G0AL  are  certainly  localized 
since  they  occur  only  in  a  single  layer  which 
corresponds  to  a  single  TIME-SLICE. 

(2)  The  debugger  can  always  see  a  consistent 
environment  by  looking  up  the  augmented 
SIMULATION-HISTORY  as  far  as  the  last  affected 
TIME-SLICE;  the  semantics  of  context  then  say  that 
the  data  seen  by  the  debugger  is  just  what  was  in 
SIMULATION-HISTORY  before  (which  is  consistent  via  the 
simulator)  except  where  contradicted  by  the  parts  that 
were  changed  by  *G0AL's  (which  are  consistent  (up  to 
that  point)  via  the  deductive  mechanisms). 

Perhaps  it  is  well  to  interrupt  here  with  an  explanatory 
d I agram. . . 
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which  Is,  due  to  the  semantics  of  context ,  equivalent  to: 


SIMULATION*  HISTORY 


which  Is  certainly  an  easier  conceptualization  of  what  has 
gone  on  so  far.  However,  the  first  picture  Is  necessary  to 
explain 
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<5)  The  lavers  whlch  record  the  changes  made  by  a  *G0AL 
(the  dashed  parts  of  the  first  picture)  can  be  peeled 
off  and  saved  at  any  time,  thus  restoring  the  context 
to  Its  original  condition  and  saving  the  effects  of  the 
•GOAL  (the  track  toward  falure)  for  further  use 

This  methodology  fills  the  bill  so  far.  Unfortunately, 
there  Is  one  final  problem  which  complicates  this  little 

Picture  (you  just  knew  there  would  be). 

This  complication  comes  from  an  as  yet 
unseen  aspect  of  the  problem-solver:  multiple  goals.  , 
mentioned  earlier  (section  3)  the  existence  of  "higher-order 
constraint  Interdependencies"  In  the  model.  (This 
weird-sound  I ng  effect  was  conveniently  kept  out  of  the 
example  In  section  2.)  We  will  see  In  section  A. 4. 2. 3  that 
higher-order  interdependency  leads  to  multiple  goals.  That 

Is-  Instead  of  simple  goals,  the  program  must  deal  with 
constructs  like: 


(*G0AL  ( *AND 


and 


(♦GOAL  ...) 
(*G0AL  ...) 
(♦GOAL  ...))) 
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( *GOAL  ( *GROUP 

( *GOAL  . ..) 

(♦GOAL  . ..) 

(♦GOAL  ...))) 

We'll  see  more  about  multiple  goals  later.  For  now  we  need 
only  examine  one  aspect  of  their  behavior. 

The  j_aj,son  d'etre  of  *AND  and  *GR0UP  is 
the  expression  of  the  fact  that  their  component  *G0AL's  are 
not  Independent.  That  Is,  the  *G0AL's  they  contain  share 
common  resources  and  cannot  be  achieved  at  each  other's 
expense.  (This  Is  how  they  model  Interdependency.)  Thus, 
the  notion  of  a  "local  constraint  environment"  varies  from 
the  one  bandied  about  earlier.  Here  we  must  have  several 
♦GOAL'S  sharing  a  single  local  environment.  Furthermore, 
because  of  the  Interdependence  of  the  *G0AL’s,  a  component 
♦GOAL  that  has  not  yet  been  completed  must  "see"  the 

constraints  posed  by  the  completion  of  other  component 

♦GOAL'S.  Thus,  the  local  constraint  environment  might 
cover  several  TIME-SLICE's. 

Clearly  this  hairs  things  up  a  bit. 

Nonetheless,  the  program  must  preserve  the  semantics  of 

•-hese  constructs  because  they  are  Important  effects  of  the 
model  which  give  rise  to  their  own  special  bugs  (see 
4. 4. 2. 3).  Actually,  given  the  flexibility  of  context*.  the 
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implementation  Is  rather  straightforward.  The  little 
schematic  of  environments  now  looks  like: 

SlMOLATIOW-mSTOR/ 
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In  terms  of  the  previous  discussion  of 
urbat Ions,  local  and  global  environments,  etc.,  nothing 

as  changed  except  that  the  -local-  environments  now  may 
aVe  3  ha'ry  mlc ^ructure  of  local  environment,- 


Uninterested  readers  may  squint  at  the  u 

squint  at  the  above  picture  (and 

concept),  leaving  everything  as  before. 

Thus,  a  .GOAL  indicates  a  local 
Perturbation.  The  deductive  mechanisms  of  ^ 

Problem-solver  follow  through  the  Interactions  defined  by 

tne  model  to  carru  «-u 

aery  the  perturbation  throughout  the 

simulation  history  In  order  to  produce  a  r  • 

^ruuuce  a  consistent 

env  ronment.  The  next  sectlon  consldFrs 

mechanisms  interaction  (v|a  ^  ^ 

bug-f I nders . 


by  PJObl  gm-gnjjily: 
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The  basic  task  of  the  program  Is  to 
trace  a  bug  from  its  manifestation  to  its  source.  This  is 
done  by  taking  In  the  manifestation  as  a  *G0AL  to  be 
achieved  (as  discussed  earlier).  The  process  of  achieving 
such  a  *GOAL  is  usually  called  "problem-solving".  But  this 
is  a  rather  special  use  of  problem-solving:  the  program 
expects  to  fail  in  the  attempt.  In  fact.  It  Is  not  until 
after  a  line  of  attack  has  failed  that  It  becomes 
Interesting  to  the  debugger.  In  this  section  we  see  how 

lines  of  attack  are  formed,  how  they  fail,  and  how  they  are 

used  after  they  fall. 

The  most  important  part  of  any 

problem-solving  process  Is  the  formation  of  subgoals  (1) 
Section  4.4.1  considers  the  methods  (those  deductive 

mechanisms  we've  heard  so  much  about)  for  devising  new 
subgoals  In  order  to  achieve  a  goal.  This  corresponds  to 
asking  the  "how  could  we  do  this  ?"  question  of  section  2. 
But  In  this  program,  the  object  of  the  problem-solver  is  not 
this  direct  attack  on  the  problem.  Instead,  the 
problem-solver  must  make  certain  It  does  not  change  the 
Intent  of  the  user's  model  In  trying  to  debu~  It. 

Thus,  the  process  of  attacking  the 


(1)  Especially  in  this  problem-solver.  Since 
rare  y  achieved,  the  whole  process 
subgoa 1 -forma  1 1  on . 


subgoals  are 
turns  Into 


user's  goal  leads  directly  Into  the  problem  of  separating 
the  constraints  which  are  In  the  simulation  history  because 
of  user  Intent  from  those  which  are  artifacts  of  unintended 
model  operation.  At  certain  key  points  in  the  deduction 

process,  the  program  determines  whether  or  not  it  should  (in 
terms  of  user  intentions)  make  the  changes  required  by  the 
deduction.  This  process  of  assigning  GOOD  and  BAD  REASON'S 
to  model  action  corresponds  to  asking  the  "why  didn't  you  do 
this  before?"  question  of  section  2.  in  4.4.2  we  examine 
this  REASONing  process  In  terns  of  the  philosophy  of  bugs 
presented  in  section  3. 

The  REASONing  process  leaves  the  program 
with  a  failed  line  of  attack.  This  appears  as  a  stream  of 
♦GOAL'S/  annotated  at  each  point  with  the  BAD  REASON  that 
triggered  further  program  action.  The  program  must  then 
examine  the  record  of  the  prool em-sol ve r  to  attach  blame  to 
the  proper  offending  model  part;  I.e.,  to  find  the  bug. 

This  task  of  post-mortem  recrimination  is  the  subject  of 
4.4.3. 

4 • 4 •  1  Ihe.  attack 

Here  we  examine  the  problem-solving 
Phase  of  the  debugging  process.  The  key  problem-solving 
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task  of  the  pros  ram  Is  to  find  the  proper  local  changes 
throughout  the  global  environment  which  will  lead  to  the 
desired  change,  since  each  desired  change  Is  represented  by 
a  *G0AL,  the  problem-solver  proceeds  by  subgoal  formation. 

The  subgoal -format Ion  parts  of  the 
Program  (the  "deductive  mechanisms"  mentioned  earlier)  are 
responsible  for  figuring  out  how  one  local  change  can  be 
brought  about  by  another.  As  an  example  of  the  way  this 
cause-effect  knowledge  Is  procedural, y  represented  In  the 
prob, en, -solver,  the  INCREASE  function  |s  presented  here. 

The  explanation  of  how  INCREASE  works  will  lead  us  directly 
Into  the  REASONing  methods  jf  4.4,2. 

The  program's  main  vehicle  for  asking 
the  "how?"  question  Is  the  INCREASE  *G0AL: 

(•goal  (INCREASE  (resource  variable  or  submodel) 
<amount>  <t ime-sl Ice)  (1)  )) 

That  is,  "goal:  Increase  the  resource  variable  or  submodel 
by  the  specified  amount  In  the  specified  time-slice."  The 
s  Initial  •COAL  Is  usually  of  the  INCREASE  type  (see 
sect  Ion  2).  This  Just  means  that  the  user's  discrepancy  Is 
usually  a  defflclsncy  of  some  resource  variable  (or  lack  of 


(1)  If.  a  <t Ime-sl Ice)  Is 
heur I st I ca 1 i y  chooses  one. 


not  given. 


the 


program 
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the  appearance  of  some  submodel)  which  he  is  asking  the 
program  to  fix  up. 

As  we  saw  in  section  4.3,  the  program 
immediately  sets  up  a  hypothetical  local  environment  In 
which  the  deficiency  has  been  rectified.  Then  it  tries  to 
deduce  an  earlier  environment  which  would  cause  the  new 
desired  simulation  state.  It  does  this  deduction  via  the 
"logic  of  INCREASE"  mentlonec  In  section  2.  The  "logic", 
briefly  stated,  runs  as  follows: 

(1)  Constant  quantities  cannot  be  I MCREASE 1 d 

(2)  In  o^der  to  INCREASE  a  quantity  that  Is  a  resource 
variable  which  Is  *OUTPUT  ( ‘REMOVE 1 d '  by  an  ‘ACTIVITY 
or  ‘EVENT,  set  up  a  new  ‘GOAL  to  INCREASE  (DECREASE) 
the  number  of  occurences  of  that  '•ACTIVITY  or  ‘EVENT 


(3)  !n  order  to  INCREASE  a  quantity  that  is  ‘RETURN'ed 
by  a  ‘FUNCTION,  set  up  a  new  INCREASE-FUNCTION  ‘GOAL  (1) 

(4)  In  order  to  INCREASE  the  number  of  occurences  of  an 
‘ACTIVITY,  set  up  (If  necessary  (2)  )  a  new  ‘GOAL  to 


(1)  INCREASE-FUNCTION's  major  ciaim  to  fame  is  that  it  sets 
up  ‘GROUP  ‘GOAL'S.  I  will  therefore  discuss  it  when  i  talk 
about  ‘GROUP  in  4.4. 2. 3  rather  than  here.  For  now  It's  okay 

1°  v  JJ  ASE  *'  UNCT'ON  as  analogous  to  INCREASE  applied 
to  ‘ACT  I  V  I TY  s . 
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INCREASE  the  resources  needed  by  that  ^ACTIVITY 

(5)  In  order  to  INCREASE  the  number  of  occurences  of  an 
♦EVENT,  set  up  a  new  *G0AL  to  INCREASE  the  frequency 
with  which  its  ^CONDITIONS  are  valid  (which  might 
include  a  *GOAL  to  INCREASE  the  number  of  occurences  of 
the  ^ACTIVITY'S  which  the  *EVENT  affects) 

Clearly,  the  Intent  of  this  list  Is  to  cover  anything  which 
the  user  or  another  part  of  the  program  (1)  might  ask  to 
INCREASE.  However,  the  rules  n  the  list  are  by  no  means  of 

uniform  character;  they  differ  greatly  in  their  logical 
bases . 

The  first  rule  can  be  viewed  as  a 
"fact",  or,  if  you  will,  a  property  of  the  concept 
Increase.  That  Is,  the  first  rule  depends  onl v  on  the 
concept  of  " I nc rea se "--not  on  MSL,  models,  etc.  The  second 
rule  expresses  a  definite  property  of  MSL  rooted  in  the 
semantics  of  *0UTPUT.  It  therefore  depends  not  only  on 

"Increase",  but  also  on  the  definition  of  MSL.  The  third 
rule,  which  will  be  discussed  later,  depends  on  "Increase", 
the  definition  of  MSL,  and  the  rules  of  mathematics  (since 


(2)  Some  necessary  resources 
sufficient  quantity. 


al  ready 


pre  sent 


(1)  Since  INCREASE  Is  defined  recursively,  the 
of  the  program"  might  be  INCREASE  Itself. 


"other  part 
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mathematical  functions  are  being  Increased).  Again,  It  Is 
valid  for  any  MSI  model.  The  fourth  and  fifth  rules  are 
different  In  a  very  Important  way.  They  depend  not  only  on 
the  definition  of  MSl  and  other  "givens",  but  also  on  the 
particular  model  defined  by  the  user. 

The  reason  for  this  is  that  the 
occurence  of  ‘ACTIVITY'S  (and  thus  ‘EVENT'S  via  the 
♦ACTIVITIES  construct  (see  4.1))  can  be  directly  determined 
by  user  Intentions.  These  Intentions  are  expressed  by  the 
♦SCHEDULE  modifier  (see  4.1).  ‘SCHEDULE  is  used  whenever 
the  modeller  wishes  to  override  the  "always  schedule  when 
possible  default  of  the  simulator.  It  therefore  determines 
the  pattern  of  ‘ACTIVITY  and  ‘EVENT  activation  throughout 
the  simulation.  ‘SCHEDULE  is  thus  the  primary  expression  of 
the  user's  policy  for  directing  the  dynamics  of  his  model. 

The  fact  that  the  "logic  of  INCREASE" 
must  take  Into  account  user  Intention  provides  the  key  link 
between  the  "how?"  and  "why  not?"  questions.  In  the  case 
of  the  first  three  rules  of  INCREASE,  the  "how?"  question  Is 
perfectly  well-formed.  The  program  need  only  look  at  what 
is  to  be  INCREASE'd  without  worrying  about  reasons  whv  It 
shouldn't  be  done.  There  are  no  reasons,  because  the  rules 
are  valid  for  any  case  the  program  can  encounter.  Thus, 
the  program  can  always  go  ahead  and  try  the  INCREASE.  It 


. .  I'-.-.'.y - -■  - m-.--/..'!  ■■■■-■  . ■■  .  ■■■■ . . . . .  ■  -..Urt.-  - - -  ■■ 
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can  either  fall  (1)  (as  In  the  case  of  INCREASIng  a 
constant,  for  example)  or  It  can  set  up  the  next  subgoal 
(usually  another  INCREASE  *G0AL)--all  without  worrying  about 
"should"  and  "shouldn’t". 

On  the  other  hand,  rules  (4)  and  (5) 
must  worry  about  "should"  and  "shouldn't"  before  setting  up 
the  next  subgoal.  Perhaps  the  user  does  not  Intend  for  the 
INCREASE  to  take  place.  Thus,  INCREASE  must  ask  the  "why 
not?"  question  before  It  proceeds. 

4.4.2  TM  voice  of  REASON 

We  saw  In  the  previous  section  that  the 
use  of  INCREASE  to  ask  the  "how?"  question  leads  directly 
to  the  need  for  the  "why  not?"  question.  As  usual,  the 
program  frames  this  question  as  a  *G0AL.  That  Is,  given  the 
♦GOAL  of  INCREASIng  an  *ACTIVITY  "A"  by  "m"  occurences  in 
TIME-SLICE  "n": 

(♦GOAL  (INCREASE  A  m  n)) 


(1)  A  failu.e  of  this  kind  is  automatically  for  a  "GOOD 
REASON"--see  sections  2  and  4. 4, 2.1. 
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the  program  Immediately  forms  the  *G0AL 

( *GOAL  (SCHEDULE  m  A  n)) 

to  ascertain  whether  or  not  INCREASE  should  proceed. 

SCHEDULE'S  job  Is  to  examine 
SIMULATION-HISTORY  and  the  user's  model  to  determine  why  the 
change  suggested  by  INCREASE  was  not  originally  part  of 
SIMULATION-HISTORY.  After  all,  since  it  presumably  leads  fo 
the  desired  state,  why  didn't  the  user  cause  the  state 
suggested  by  INCREASE  In  the  first  place? 

There  are  two  kinds  of  reasons  for  the 
user's  not  causing  the  suggested  state  to  occur  Initially. 
A  GOOD  REASON  Is  that  he  deliberately  intends  (for  reasons 
best  known  to  himself)  the  model  not  to  allow  that  state. 
A  BAD  REASON  Is  that  the  Interaction  of  the  submodels  has 
caused  a  constraint  which  disallows  the  state.  A  BAD  REASON 
Is  not  a  bug.  It  simply  Implies  that  a  constraint  is  due  to 
submodel  interaction  and  not  user  Intention.  However,  given 
the  bug  philosophy  of  section  3,  the  program  treats  a  BAD 
REASON  as  "susp l c t ous"--a  cause  for  further  Investigation. 

In  this  section  we  examine  the  way  the 
program  distinguishes  GOOD  Ri-ASON's  from  R AD  REASON'S  (and 
the  way  It  classifies  BAD  REASON'S).  The  next  subsection 
discusses  the  program's  model  of  user  intent-- 1  .e . ,  Its 


GOOD  REASON'S 
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we 


method  for  discerning 
classify  BAD  REASON'S  along 
"Interaction  bugs"  presented  In 


the  1  I nes 
sectlor  3. 


After  this# 
of  the  three 


4. 4. 2.1  GOOD  REASON'S 


At  each  stage  of  the  debugging  process# 
the  program  Is  trying  to  change  an  env I ronment . . . by  using  a 
resource#  Inserting  a  new  submodel , etc.  In  order  to  do 
this#  the  program  must  face  the  question  of  whether  or  not 
the  change  shoul d  (In  terms  of  user  Intentions)  be  made. 
Of  course#  it  Is  unreasonable  to  expect  the  user  to  have  to 
tell  tha  program  at  each  step  what  should  and  should  not  be 
changed.  In  fact#  given  the  philosophy  of  section  3#  It  Is 
very  unlikely  that  the  user  could  provide  this  Information 
If  he  v/anted  to.  Thus#  the  program  needs  some  sort  of 
theory  of  which  of  the  constraints  found  In 
SIMULATION-HISTORY  are  use r- l ntended  and  which  are  there 
because  of  a  possible  bug  In  the  model. 

Going  back  to  sections  1.3.1  and  3#  we 
recall  the  previous  assumptions  about  user  Intentions:  the 
user  has  a  good  understanding  of  each  submodel#  but  only  a 
very  weak  understanding  of  how  submodels  Interact  to  achieve 
an  overall  goal.  Thus#  the  program  can  assume#  at  least 
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temporarlly/  that  all  Information  In  the  simulation  history 
which  Is  derived  directly  from  user  statements  about  an 
individual  submodel  Is  use r- I ntended .  All  other  Information 
Is  necessarily  the  result  of  submodel  Interaction  and  Is 
therefore  suspect.  The  programming  task  is  to  Interpret 
this  simple  theory  (1)  of  user  Intention  In  terms  of  the 
deductive  mechanisms  and  SIMULATION-HISTORY. 

Everything  In  an  MSL  specification 
pertains  only  to  a  specific  submodel;  this#  In  fact#  was  a 
design  criterion  (see  4.1).  Thus#  everything  so  far  Is 
user- Intended#  by  our  principle  of  locality.  But  this  Is 
only  static  information.  Once  the  model  Is  simulated#  some 
of  this  static  local  Information  gives  rise  to  Interaction 
between  submodels.  The  question  then  becomes  one  of 
determl ng  how  locality  is  preserved  in  the  dynamic  behavior 
of  the  model.  That  is#  what's  local  about 
SIMULATION-HISTORY? 


According  to  4.3#  the  answer  seems  to  be 
that  the  TIME-SLICE  Is  used  by  the  program  as  a  "local 


(1)  This  theory  Is  of  course  quite  liberal  in  its  suggestion 
of  "suspect"  constraints.  At  this  stage#  this  seems  to  be 
the  best  strategy.  The  deductive  mechanisms  are  capable  of 
eliminating  non-bugs  rather  easily  so  that  things  don't  blow 
up  (see  section  2).  However#  If  really  large  models  were 
used#  a  better  theory  would  be  necessary  to  avoid  smothering 
the  program  with  possible  leads  (see  section  4.5). 
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environment". ..but  why?  The  TIME-SLICE  preserves  locality 
because  direct  user  policy  Is  at  the  TIME-SLICE  level. 
Scheduling  decisions  set  certain  *ACTIVITY's  to  occur  In 
certain  TIME-SLICE's  (see  description  of  *SCHEDULE  In  4.1). 
♦PREREQUISITES  are  checked  at  the  TIME-SLICE  level ,  ♦OUTPUT 
occurs  at  the  TIME-SLICE  level,  *FUNCTI0N'5  are  called, 
♦EVENT'S  triggered, etc. --al  1  at  the  TIME-SLICE  level.  All 
of  the  direct  user  decisions,  as  specified  by  the  static 
Information  In  the  MSL,  affect  the  simulation  at  the 
TIME-SLICE  level.  Therefore,  the  program  takes  a  constraint 
to  be  local  (and  thus  user- intended)  if  It  depends  only  on 
what  happens  in  a  single  TIME-SLICE. 

Now  I  mentioned  In  1.3.1  that  the  models 
used  In  this  thesis  are  especially  Interactive. 
Furthermore,  as  l  said  above,  the  criteria  for  suggesting 
unintended  constraints  can  afford  to  be  liberal--we  would 
rather  suggest  wrong  bugs  than  miss  a  possible  bug.  Thus, 
we  would  expect  there  to  be  few  local  "user- Intended" 
constraints  and  many  non-local  "suspect"  constraints.  This 
Is  Indeed  the  case.  The  resources  present  In  any  TIME-SLICE 
are  dependent  on  the  action  of  the  model  over  many 
TIME-SLICE's  and  are  thus  non-local.  Similarly,  the  timing 
of  * ACT  I  V I TY ' s  which  do  not  contain  *SCHEDULE  specifications 
becomes  resource-dependent  and  thus  non-local.  *EVENT 
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occurences  are  specified  ny  probabilistic  functions  of 
resources  and  are  thus  non-local.  Finally,  higher-order 
constraints  like  coincident  presence  of  several  resources 
span  several  TIME-SLICE's  (see  4.3)  and  are,  almost  by 
definition,  non-local.  These  non-local  constraints  give 
rise  to  the  BAD-REASON's  discussed  In  the  next  two 
subsections.  For  now,  let's  mention  the  few  GOOD  REASON'S 

that  exist. 

Most  GOOD  REASON'S  concern  constraints 
that  arise  from  ‘SCHEDULE  constructs.  If  the  change 
requested  by  INCREASE  would  violate  the  ‘ACTIVITY'S 
‘SCHEDULE  for  that  TIME-SLICE,  SCHEDULE  denies  the  request 
for  GOOD-REASON  (1)  .  Thus,  If,  as  In  section  2,  there  are 
three  ADVERTISING  ‘ACTIVITY'S  already  In  a  TIME-SLICE  and 
ADVERTISING  contains  the  modifier 

(‘SCHEDULE  3) 


SCHEDULE  will  deny  a.iy  request  to  up  the  amount  of 
ADVERTISING  In  that  TIME-SLICE.  Similarly,  SCHEDULE  views 
the  other  avatars  of  ‘SCHEDULE  (see  4.1)  as 

GOOD-REASON-generators. 

The  other  kinds  of  GOOD  REASON'S  are 


(1)  There  Is  one  exception  to 
In  the  next  subsection. 


this  which  will  be  discussed 
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those  that  are  based  on  "fact"  or  are  "true  by  definition" 
(see  the  first  three  rules  of  INCREASE  in  4.4.1).  Thus, 
SCHEDULE  will  deny  attempts  to  schedule  In  negative  time, 
increase  constants,  etc.  for  GOOD  REASON.  Actually,  these 
REASON'S  can  be  viewed  as  being  based  on  the  "common  sense 
knowledge"  the  user  has  In  addition  to  his  knowledge  about 
submodels.  That  is,  the  user  directly  intends  nls  model  to 
be  "sensible"  as  well  as  to  be  in  accordance  with  known 
submodel  constraints. 

Thus,  GOOD  REASON'S  apply  to  constraints 
which  depend  only  on  single  TIME-SLICE  Information,  i.e., 
which  reflect  the  locality  which  Is  characteristic  of  user 
Intention.  We  now  go  on  to  Investigate  the  way  In  which  the 
program  deals  with  non-local  constraints. 

4. 4. 2. 2  Basis  ME  REASON'S 

If  the  program  cannot  find  a  GOOD  REASON 
for  a  constraint,  it  must  attribute  Its  existence  to  a  BAD 
REASON.  From  the  "interaction  bug"  philosophy  of  section  3 
we  see  that  the  user's  understanding  of  his  model  falters  in 
the  three  critical  areas  mentioned  at  the  beginning  of  this 
sect  Ion: 


(1)  the  effects  of  resource  competition  among  submodels 

(2)  timing  effects  of  submodels 

(3)  the  effects  of  higher-order  constraints 

If  a  constraint  is  there  for  no  GOOD  REASON,  the  program 
considers  the  possibility  that  the  constraint  arose 
unintentionally  from  one  of  these  three  misunderstandings. 
It  will  therefore  try  to  come  up  with  a  BAD  REASON  for  the 
constraint's  existence  so  that  it  can  Inform  the  debugger  of 
the  possible  anomaly  (see  section  4.4.3),  This  section 
will  consider  the  BAD  REASON'S  related  to  the  first  two 
kinds  of  Interaction.  These  BAD  REASON'S  form  the  basis  for 
BAD  REASON'S  arising  from  higher-order  I nte rdependenc les--as 
discussed  In  4. 4. 2. 3.  Mow,  to  continue  with  our  favorite 
process,  the  SCHEDULE  *G0AL  was  just  seeing  why  the  desired 
•ACTIVITY  wasn't  scheduled  in  that  TIME-SLICE  in  the  first 
Place. . . 

Since  the  user  didn't  specifically  ask 
for  the  ^ACTIVITY  not  to  be  scheduled,  there  can  be  only  two 
reasons  why  the  *ACTIVITY  wasn't  there: 

(1)  some  of  its  prerequisite  resources  weren't  present 


Page  98 


(2)  It  Is  dependent  on  an  ‘EVENT  that  didn't  occur 

Thus,  the  program  first  checks  out  the  resource  situation  In 
the  TIME-SLICE.  If  the  resources  are  not  sufficient  to 
support  the  ‘ACTIVITY,  there  can  be  two  reasons  why: 

(1)  the  resources  were  available  In  the  TIME-SLICE  but 
were  used-up  by  h I ghe r-pr I  or 1 1 y  ‘ACTIVITY'S  before  the 
♦ACTIVITY  In  question  got  a  chance  at  them 

(2)  the  resources  just  ain't  there 

To  check  out  the  first  possibility,  the  program  looks  at  the 
status  of  the  h I gher-pr I  or 1 1 y  ‘ACTIVITY'S  In  the  TIME-SLICE. 
If  any  of  these  ‘ACTIVITY'S  Indeed  "stole"  resources  which 
would  have  allowed  scheduling  of  the  desired  ‘ACTIVITY, 
their  names  are  collected  and  the  BAD  REASON 

(PRIORI TY- RE SOURCE-BOUND  (<names  of  offending  *ACTI V 1 TY ' s> ) ) 
Is  recorded. 

If  no  h I gher-pr I  or  I ty  ‘ACTIVITY'S  stole 
the  resources,  then  the  resources  must  just  have  been  absent 
from  the  TIME-SLICE  In  the  first  place.  The  ubiquitous 
two  possible  reasons: 
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(1)  The  ^ACTIVITY'S  which  ^OUTPUT  the  desired  resources 
weren't  scheduled  until  It  was  too  late  for  the 
resources  to  be  available  In  the  TIME-SLICE 

(2)  The  ^ACTIVITY'S  which  ^OUTPUT  the  desired  resources 
were  scheduled  too  early  aid  the  resources  were 
gobbled  up  by  li  I  gher-pr  I  or  1 1  y  ^ACTIVITY'S  In  the 
Intervening  TIME-SI.  I  CE' s 

Of  course.  In  either  Instance,  the  user  nay  have  I ntended 
this  to  be  the  case  (well  we  know  how  to  check  that  out...). 
On  the  other  hand,  the  *OUTPUT  *ACTIV|TY's  may  have  ended  up 
In  the  wrong  place  because  of  the  user's  poor  understanding 
of  timing  effects  (1)  --a  BAD  REASON.  To  determine  which  Is 
the  case,  the  program  proceeds  as  follows.  It  first  finds 
out  what  *ACTIV|TY's  *OUTPUT  the  desired  resources  and 
checks  to  see  If  they  were  scheduled  too  late  to  do  the 
desired  *ACTIVITY  any  good.  Then,  It  sees  whether  the 
♦  OUTPUT  * ACT  I  V  I TY ' s  were  "late"  for  GOOD  REASON.  If  not.  It 
notes  a  BAD  REASON: 


(1)  Note  that  the  "Interaction  Information"  about  timing  Is 
Implicit  In  the  resources.  That  !s,  there  are  no  explicit 
timer-alarms  to  say  when  something  Is  too  late  or  too  early. 
The  only  evidence  of  a  timing  error  In  the  model  will  be 
found  In  the  levels  of  particular  resources  over  time. 
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(RESOURCE-BOUND  (TOO  LATE  <<names 
of  offending  ‘ACT I V I TY *  s> ) ) ) 


If  there  are  no  "late''  ‘ACTIVITY'S,  or  If  the  ‘ACTIVITY'S 
were  late  for  GOOD  REASON,  the  program  looks  back  up  the 
SIMULATION-HISTORY  for  two  things:  ‘ACTIVITY'S  which  ‘OUTPUT 
the  needed  resources  scheduled  "too  early"  for  no  GOOD 
REASON  and  "Interloping"  ‘ACTIVITY'S  of  higher  priority 
which  stole  the  needed  resources.  If  both  of  these  things 
exist,  the  program  notes: 

(RESOURCE-BOUND  (TOO-EARLY  (<names  of  offending  ‘ACTIVITY'S) 
((names  of  Interloping  ‘ACT I V I TY ' s> ) ) ) 

Thus,  the  PRIORITY-RESOURCE-BOUND  and 
RESOURCE-BOUND  BAD  REASON'S  take  care  of  the  case  In  which 
the  ‘ACTIVITY  cannot  be  scheduled  because  of  a  lack  of 
prerequisite  resources  (1)  .  This  leaves  the  other  case  In 
which  the  ‘ACTIVITY  could  not  be  scheduled  because  It  Is 


(1)  As  discussed  previously,  the  prograr  would  try  to 
alleviate  this  def . iclency  with  an  appropriate  INCREASE 
‘GOAL.  The  reason  for  this  Is  to  make  sure  that  the  program 
traces  through  the  entire  Interaction  path:  after  all,  this 
resource  deff Iclency  could  just  be  the  result  of  an  earlier 
decision  which  reflects  the  actual  bug.  More  on  this  In 
4.4.3. 
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dependent  on  an  ‘EVENT  that  didn't  occur. 

The  program  can  easily  recognize  this 
second  case  because  It  can  only  arise  from  the 


(♦SCHEDULE  (ON  <*EVENT-name>  ) ) 


specification  (see  4.1).  If  the  specified  *EVENT  did  not 
occur  in  the  TIME-SLICE,  the  desired  *ACTIV!TY  could  not  be 
scheduled.  Now,  if  the  program  were  acting  like  it  did 
before,  it  wou’d  try  to  find  out  "why"  the  *EVENT  didn't 
take  place  in  the  TIME-SLICE.  However,  this  Is 
Inappropriate  for  *EVENT's,  which,  after  all,  model 
occurences  which  are  beyond  the  modeller's  direct  control. 
Of  course,  this  raises  the  question  of  why  a  modeller  would 
make  an  *ACTIV!TY  dependent  on  ar  *EVENT  in  the  first  place. 
Indeed,  the  program  becomes  suspicious:  It  Is  possible  that 
because  of  the  user's  poor  understanding  of  timing  effects, 
the  *EVENT  dependency  (plus  the  time  needed  by  the 
♦ACTIVITY)  will  cause  the  ♦ACTIVITY  to  take  effect  at  the 
wrong  time-  dually  too  late  (1)  .  The  rrogram  checks  out 


common  cause  of  this  *EVENT-dependency  is  the 
e  fight!  g  approach  to  solving  problems:  when  the  event 
occurs,  start  doing  something  cbout  it.  (This  Is,  In  fact, 

on^Sl??  S?  "  tM%eX^Ple  ^  sect,on  2:  H,R,NG  Is  dependent 
on  QUITTING.)  Note  that  this  BAD  REASON  is  the  exception 


to  the 
referred 


"If  ‘SCHEDULE 
to  earl  le r . 


says  It's  okay,  it's  okay"  dictum 
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this  possibility  by  looking  up  and  down  SIMULATION-HISTORY 
to  see  If  the  ^ACTIVITY  was  scheduled  “too  late"  or  "too 
early".  If  either  of  these  Is  whe  case#  the  program  notes  a 
BAD  REASON: 

( *EVENT-TR 1 GGCRED-SCHt  3ULE  <offendlng  *ACTIVITY> 

<"T00  LATE"  or  "TOO  EARLY"> ) 

If  neither  of  these  Is  the  case#  the  program  simply 
terminates  Its  line  of  attack  (1)  on 

( *EVTNT-TP 1 GGERED-SCHEDULE ) 


ard  goes  away  mumbling  to  Itself  (actually#  this  would  be 
the  first  "GOOD  REASON"  It  looks  at  after  all  the  BAD 
REASON'S  were  checked  by  the  debugger). 


Well#  this  wraps  up 

the 

ii 

basic 

BAP 

reason's"  arising 

from  poor  understanding 

of 

resource 

conflict  and  timing 

effects.  Now  we  go 

on 

to 

see 

how 

misunderstanding  of  higher-order  constraints  leads  to  the 
use  of  these  same  BAD  REASON'S  In  an  expanded  context. 


(1)  Note  that  unlike  the  other  BAG  REASON'S#  this  one  causes 
the  line  of  attack  to  terminate — no  further  Investigation  Is 
possible  (see  4.4.3). 
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4. 4. 2. 3  Higher-order  £AD  REASON'S 

Up  until  now  (except  for  part  of  4.3),  I 
have  ove r-s I mpl I f I ed  the  Interactive  behavior  of  submodels 
for  the  purposes  of  discussion.  Specifically,  I  have 
pretended  that  a  submodel  can  depend  on  only  one  other 
submodel  for  its  sources  of  Input.  Thus,  my  *ACTIVITY's 
have  had  only  one  unfilled  *  PRE  REQU IS  I TE ,  my  ♦FUNCTION'S 
only  one  *ARGUMENT.  This  Is  of  course  quite  unrealistic, 
and  not  a  real  restriction  of  MSL.  In  this  section  I  remove 
this  artificial  restriction. 

The  Introduction  of  multiple  dependency 
brings  up  the  Issue  of  higher-order  constraints.  As  we  saw 
in  4.3,  when  submodels  depend  on  several  other  submodels  for 
input,  the  problem-solver  must  take  into  account  the 
illtfcrrel  at  lonsh  I  p  of  the  input  ♦ACTIVITY'S.  The  Input 
♦ACTIVITY'S  are  in  fact  operating  under  a  "higher-order 
constraint"  (see  section  3,2)--they  must  combine  to  provide 
resources  for  a  single  ^ACTIVITY  (or  ♦FUNCT.JN)  at  a  certain 
time  .  This  higher-order  constraint  Is  modelled  by  forcing 
the  Input  ♦ACTIVITY'S  to  share  a  local  constraint 
environment  (see  4.3).  That  Is,  all  *ACTIVITY's  sharing  a 
higher-order  constraint  must  be  scheduled  not  only  in 
accordance  with  their  own  needs,  but  also  with  the  needs  of 
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.he  ‘ACTIVITY  or  ‘FUNCTION  that  depends  on  them.  There  are 
two  types  of  env I ronmen t-sha ring,  reflected  by  two  types  of 
♦GOAL's  to  handle  the  higher-order  dependencies.  The  first 
of  these  Is  *AND/  the  expression  of  the  way  ♦ACTIVITY'S 
depend  on  each  other  when  their  higher-order  constraint  Is 
another  *ACTIViTY.  The  second  Is  *GR0UP/  which  models  the 
♦ACTIVITY-‘FUNCTICN  dependency. 

♦AND  dependency  arises  from  *ACTlVITY's 

that  1 ook  1  |  ke 


(♦ACTIVITY  SALES-CALL 

(♦"REREQUISITES 
( *AND 


SALESMAN))) ) 


(♦PRESENT  (1000  CASH) ) 
(♦PRESENT  (1  UNIT)) 
(♦PRESENT  (SOME 


That  Is,  SALES-CALL  depends  on  the  submodels  which  *CUTPUT 
CASH, UNIT,  and  SALESMAN.  A1  1  of  these  *0UTPUT's  must  be 
present  at  once  (l.e..  In  the  same  TIME-SLICE).  Thus,  any 
♦GOAL  which  tries  to  schedule  a  new  SALES-CALL  ‘ACTIVITY 
must  take  this  Into  account.  Specifically,  If  the  resources 
are  not  available,  al]  of  the  ‘OUTPUT  ‘ACTIVITY'S  Involved 
must  be  scheduled.  That  Is,  given  th<>  *G0AL 


(♦GOAL  (INCREASE  SALES-CALL  m  n)) 
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and  assuming  none  of  the  necessary  resources  are  on  hand  (1) 

,  the  program  must  generate  the  subgoal 
( *G0AL 

(♦AND 

(♦GOAL  (INCREASE  CASH  j  n)> 

(♦GOAL  (INCREASE  UNIT  k  n)) 

(♦GOAL  (INCREASE  SALESMAN  1  n)) 

)) 

Now,  just  as  before,  the  program  must  be 
careful  not  to  INCREASE  things  contrary  to  the  intentions  of 
the  user.  Again,  It  uses  the  SCHEDULE  ♦GOAL  to  find  out  the 
REASON  for  constraints.  However,  the  SCHEDULE  *GOAL  cannot 
slmpiy  check  out  each  INCREASE  *G0AL  Independently  as 
before.  The  INCREASE  *GOAL's  are  now  Interdependent  and 
must  be  treated  as  such.  So  now,  finding  GOOD  and  BAD 
REASON'S  is  a  whole  new  game. 

Mot  really.  Fortunately,  the  process 
Isn't  very  different,  especially  In  the  case  of  *AND.  First 
of  all,  examination  of  the  whole  GOOD  REASON-f  I  nd  i  ng 
philosophy  and  implementation  will  show  that  it  is 
completely  unaffected  by  higher-order  Interdependencies. 
This  is  almost  by  definition:  GOOD  REASON'S  pertain  to 

individual  submodels  and  TIME-SLICE's,  while  higher-order 

% 


(l)  In  section  2  I  kept  higher-order  constraints  out  of  the 
picture  by  buffering  away  dependencies.  Thus,  In  the  case 
of  SALE5-CALL,  all  resources  except  SALESMAN  were  available 
already  (see  section  2). 
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Interdependencies  transcend  these  boundaries  of  locality. 
Thus,  SCHEDULE'S  GOOD  REASON l ng  processes  are  still  the 
same.  Certainly,  however,  the  BAD  REASON l ng  Is  different. 
But  most  of  the  differences  have  been  taken  care  of  already 
by  the  environment-sharing  discussed  In  4.3.  That  Is,  the 
effects  of  higher-order  constraints  on  resource  conflicts 
and  time  dependencies  are  already  reflected  In  the  way  *AND 
♦GOAL'S  are  set  up  and  processed--the  higher-order 
Interdependency  Is  already  modelled.  For  example,  if 
satisfying  one  component  *GOAL  steals  resources  from  another 
or  disturbs  the  timing  of  another,  the  shared  environment 
will  make  this  Interaction  explicit:  the  resources  needed  by 
each  *G0AL  are  recorded  separately  so  that  the  effects  of 

everything  done  in  the  *AND  environment  can  be  traced  to  the 
proper  source. 

All  this  Is  saying  that  all  SCHEDULE  has 
to  do  about  *AND's  Is  to  realize  that  It  Is  In  a  shared 
environment  and  attribute  BAD  REASON'S  to  the  effects  of 
sharing.  Thus,  the  searches  for  higher-priority  *ACTlVlTY's 
and  timing  problems  which  were  previously  carried  out  only 
In  a  single  TIME-SLICE  are  now  carried  out  In  the  whole  *AND 
environment.  The  "new"  BAD  REASON'S  they  generate  look  like 

(PRIORITY-RESOURCE-BOUND  (<names  of  offending 
♦ACTIVITY’S))  ♦AND-MODE) 

(RESOURCE-BOUND  (TOO-EARLY  (<names 
of  offending  *ACT!VlTY's>) 
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*AND-M0DE  (<names  of  Interloping  *ACTIVITY's 
In  the  *AND  environment))  (<names  of  other 
Interloping  *ACT I V ITY ' s> ) ) 

etc. 

The  theme  here  I  that  most  of  the  work 
for  finding  higher-order  BAD-REASON's  In  the  *AND  case  was 
done  by  setting  up  the  *'AND  environment  in  the  first  place. 
That  Is#  the  I nterdependency  Is  already  explicitly  modelled 
by  the  way  *AND  *G0AL's  work,  and  need  only  be  checked 
through  by  SCHEDULE  to  find  the  appropriate  BAD  REASON'S. 
This  theme  Is  elaborated  for  the  *GR0UP  case. 

In  4.4.1  I  postponed  the  Issue  of 
INCREASIng  *FUNCTION's  by  attributing  this  task  to  a 
separate  INCREASE-FUNCTION  *G0AL-type.  The  job  of 

INCREASE-FUNCTION  Is  to  figure  out  a  way  to  Increase  the 
value  *RETURN'ed  by  a  *FUNCTI0N  by  changing  the  values  of 
Its  *ARGUMENTS  (thus.  It  is  completely  analogous  to 
INCREASE).  Obviously,  this  problem  Is  extremely  difficult 
for  a  large  class  of  functions.  Fortunately,  the  functions 
needed  In  business  games,  and.  Indeed,  in  most  of  business 
processing,  are  of  a  very  simple  nature  (1)  .  MSL  currently 


(1)  The  mathematics  of  management  sc  I  ence-- 1 .e . ,  mathematics 
meant  to  model  systems  and  decl slons--can  be  quite 
sophisticated,  but  this  Is  not  business  processing.  Indeed, 
even  In  a  business  game,  the  probability-handling  can  get 
tricky.  But  all  of  this  Is  built  Into  MSL--the  user  can 
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allows  the  representation  of  only  two  kinds  of  functional 
dependencies:  tables  and  linear  functions  of  a  few 
variables.  The  mathematical  techniques  for  Increasing  these 
♦FUNCTION'S  are  simple  and  are  not  of  Interest  here.  The 
Interesting  part  of  ♦FUNCTION'S  for  this  discussion  Is  they 
are  responsible  for  the  second  kind-  of  higher-order 
I n  terdependency . 

We  just  saw  how  the  relation  between 
♦PREREQUISITES  and  *0dTPUT's  causes  *AND  Interdependency. 
Similarly,  the  relation  between  *ARGUMENTS  and  *RETURN'ed 
value  causes  *GR0UP  I n te rdepency .  In  tne  *AND  case,  the 
Interdependency  was  that  aH  *PREREQU  I S I TES  must  be  present 
in  the  proper  quantities  In  a  single  TIME-SLICE  for  the 
♦ACTIVITY  to  be  Initiated.  *GR0UP  Interdependency  Is 
weaker.  We  know  only  that  agrje  combination  pf  changes  to 
the  components  will  bring  about  the  desired  change  to  the 
higher-order  constraint.  That  is,  each  subgoal  can 
contribute  an  unspecified  amount  to  the  success  of  the 
overall  *G0AL.  Perhaps  the  increase  of  only  one  of  the 
♦ARGUMENT  resources  will  suffice  to  increase  the  *RETURN'ed 
value.  Or,  all  may  be  nece ssa ry--mak I ng  the  *GR0UP  an  ♦AND 
at  the  extreme. 

Now  the  program  must  model  this  kind  of 

only  define  simple  funct Ions  which  uTe  the  probabl 1  I ty 
machinery. 
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Interdependency  when  It  tries  to  INCREASE  *FUNCTION's. 
Furthermore,  In  trying  to  solve  the  INCREASE-FUNCTION 
problem.  It  must  go  about  the  task  pretty  much  the  same  way 
organizations  do  In  order  .o  run  Into  the  same  kind  of 
Interactive  behavloi .  That  Is,  the  Interaction  Involved  In 
a  kind  of  breadth-first  approach  to  the  problem  (Increase 
each  ^ARGUMENT  resource  a  little  In  turn  until  the 
♦RETURN 'ed  value  has  been  IMCREASE'd  the  desired  amount) 
causes  very  different  subgoal  Interaction  than,  say,  a 
depth-first  approach  (Increase  each  ^ARGUMENT  as  much  as 
possible  separately  to  see  how  much  It  helps  to  INCREASE  the 
♦FUNCTION).  The  differences  are  In  which  subgoals  are 
allowed  to  be  achieved  at  the  expense  of  others  (1)  ,  the 
range  of  subgoals  tried,  and  the  extent  to  which  each 
subgoal  Is  exercised  (2)  .  Clearly,  different 
Interdependencies  are  tapped  by  different  subgoal  attack 
methods . 

So  the  program  must  try  to  overcome  the 


(1)  Unlike  *AND,  this  Is  allowed  because  not  all  *GR0UP'ed 
subgoals  must  be  achieved.  The  only  requirement  Is  that  all 
of  the  subgoals  which  eventual  1 v  succeed  must  share  the  same 
local  constraint  environment  (otherwise  the  construct 
doesn't  model  higher-order  Interdependency). 

(2)  Note  that  this  need  to  model  the  organization's 
problem-solving  method  was  not  present  In  the  *AND  case. 
Since  all  subgoals  must  be  achieved  as  stated,  no 
" re  sou rce -stea 1  I ng"  Is  allowed  among  them  and  all  of  them 
must  be  fully  tried  and  executed. 
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higher-order  constraint  of  Increasing  a 

functionally-determined  value  the  same  way  organ  1 zat . ons  do. 
Obv I ousl y,  this  Is  a  tall  order.  First  of  all,  functional 
relationships  are  usually  Implicit  In  organizations,  not 
explicit  as  In  MSI  —  so  It's  hard  to  see  what  organizations 
do  about  them.  Second,  It  Is  reasonable  to  assume  that 
different  organizations  attack  different  functional  problems 
In  different  ways  at  different  times.  Finally,  It  Is 
possible  that  the  actual  process  Is  not  pre-deflned  at  all 
In  many  cases,  but  Is  Instead  made-up  and  modified  during 
the  course  of  each  problem's  solution.  What  I  am  trying  to 
say  by  all  of  this  Is  that  I'm  not  about  to  solve  the  whole 

problem  or  even  a  very  big  part  of  It... 

What  I  have  done  Is  to  program  a  single, 

slightly  sophisticated  method  of  attacking  higher-order 
functional  constraints  which  attempts  to  model  one  way  In 
which  an  organization  might  do  It.  It  should  be  seen  as  an 
experiment  for  demonstrating  the  approach  of  the  program  In 
dealing  with  this  kind  of  constraint,  not  a  fully  developed 
piece  of  the  system.  This  part  of  the  program.  Incorporated 
In  INCREASE-FUNCTION,  works  as  follows:  given  a  *G0AL  of  the 
form 

(♦GOAL 

(♦GROUP 

(♦GOAL  (INCREASE  argumentl  tlmel)) 
(♦GOAL  (INCREASE  argument2  tlme2)) 
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)) 

the  program  takes  the  first  ‘GOAL 

(♦GOAL  (INCRFASE  argumentl  tlmel)) 

and  tries  to  INCREASE  argumentl  the  minimum  possible  amount 
as  a  "feasibility  study".  It  carries  the  ‘GOAL  all  the  way 
to  completion.  If  It  can.  If  the  *GOAL  Is  unsuccessful 
(for  GOOD  REASON),  It  Is  wlthdrwan  from  the  ‘GROUP  and  the 
program  does  a  "feasibility  study"  on  the  next  *GOAL  In  the 
♦GROUP .  If  no  "feasibility  study"  Is  successful,  the  whole 
♦GROUP  naturally  falls.  Now,  If  any  of  the  "studies"  are 
successful,  the  program  will  keep  attacking  the  studied  1  ne 


until  It 

falls. 

When 

this  happens,  l.e.. 

when  the 

particular 

♦ARGUMENT 

has 

been  INCREASE'd  as 

much  as 

possible. 

the  program  considers  Itself  to  have 

a  "partial 

success".  That  Is,  the  effect  o*  the  INCREASE'd  ‘ARGUMENT 
Is  now  calculated  Into  the  overall  *GROUP  *GOAL,  so  that  a 
new  *GROUP  *GOAL  Is  formed  such  that 

(1)  The  fully  INCREASE'd  ‘GOAL  Is  no  longer  In  the 
♦GROUP 

(2)  The  overall  ‘GOAL  Is  reduced  by  the  amount 
contributed  by  the  successfully  INCREASE'd  ‘GOAL 
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In  this  flea  ‘GRO'JP  environment, 

enrpsstd  until  success 
similarly  processea 


the  other 
(or  failure) 


All  of  this  hopefully 


♦  GOAL'S  i  re 
occurs . 
goes  toward 


modelling  the  way  an  organization  attacks  this  kind  of 
problem:  by  checking  out  and  eliminating  possibilities  one 
by  one#  and  pushing  winning  lines  as  far  as  possible  to 
achieve  the  overal 1  *G0AL,  As  Intimated  In  4.3,  the  process 
Is  modelled  (like  *AMD)  by  the  proper  sharing  of 
environments.  Obviously,  the  environment-hackery  for 
♦GROUP'S  is  a  bit  more  complicated  than  for  *AND  (for 
example.  It  must  Incorporate  the  notion  of  "partial  success" 
and  the  fact  that  all  the  eventually  successful  *G0AL's  and 
only  the  eventually  successful  ♦GOAL'S  share  the  same  local 
constraint  environment).  The  question  for  us  here  is  how 
this  affects  the  GOOD  and  BAD  REASONIng  process. 

Again,  the  answer  is  "not  all  that 
much".  As  with  the  *AND  case,  the  only  difference  is  that 
the  BAD  REASON'S  differentiate  between  constraints  caused  by 
higher-order  interaction  and  those  caused  by  other  kinds  of 
interaction.  This  !s  again  just  a  matter  of  tracing  through 
the  explicit  relationships  set  up  in  the  *G0AL's  environment 
structure.  As  far  as  actual  BAD  REASON'S  for  constraints 
go,  *GR0UP  only  adds  two  (minor)  new  wrinkles.  First  of 
all,  St  will  make  a  special  notation  if  the  constraint  comes 


Pape  113 


up  during  a  feasibility  trial.  Second,  It  carefully  notes 
which  *GPOUP  *GOAL '  s  have  already  succeeded  when  the 
constraint  comes  up.  These  are  just  convenience  factors 
which  the  bug-finder  uses  when  suggesting  *GR0UP  bugs  to  the 
user;  It  wants  to  make  clear  exactly  what  the  program  was 
doing  when  It  ran  Into  the  constraint.  This  Is  Important, 
because,  as  mentioned  above,  different  Interaction  occurs 
depending  on  exactly  what  the  program  does. 

This  brings  up  a  final  Important  point. 
•GROUP  BAD  REASON'S  are  perhaps  the  weakest  In  the  REASON 
repertoire  because  they  depend  directly  on  the  actual 
exploration  methods  used.  That  Is,  the  program  might 
suggest  a  CAD  REASON  which  the  user  may  never  really 
encounter  because  of  the  way  his  organization  handles 
functional  dependencies.  Thus,  the  debugger  saves 
♦GROUP-type  hugs  for  last.  Nonetheless,  I  think  that  It  Is 
very  Important  to  Include  this  kind  of  REASONIng  In  the 
debugger;  *GR0UP-sty1e  dependencies  are  pervasive  In 
organizations.  Furthermore,  they  point  the  way  toward 
modelling  more  sophisticated  kinds  of  submode  1 -submode  1 
Interactions  .  The  weakness  of  the  ‘GROUP  method  In  this 
program  Is  Its  Incompleteness,  not  T.  s  basic  concept. 

This  section  has  catalogued  all  of  the 
BAD  REASON'S  generated  by  the  program.  Now  we  finally  get 


Page  114 


around  to  finishing  the  bug  story  bv  showing  how  the  BAD 
REASON’S  are  used  to  suggest  the  actual  model  bugs. 


4.4.3  JM  post-mortem  rec r  I m i nat  i ons 

So  far#  the  debugger  has  been  left  with 
a  bunch  of  GOOD  and  BAD  REASON'S  for  constraints.  It  Is  now 
time  to  turn  these  Into  bug  suggestions.  So#  let's  see  what 
the  REASON'S  mean  to  the  debugger.  If  the  problem-solver  Is 
faced  with  a  BAD  REASON  for  a  constraint.  It  knows  that  the 
constraint  Is  based  on  submodel  Interaction.  Its  job  Is  to 
explore  that  Interaction.  Therefore,  when  SCHEDULE  returns 
a  BAD  REASON,  the  probl em- sol ver  considers  It  a  cause  for 
further  Investigation.  In  this  way.  It  carries  the 
perturbation  as  far  as  It  can--traclng  the  Interaction 
patterns  to  their  roots. 

GOOD  REASON'S  are  the  "roots"  that  stop 
this  search,  through  the  interaction  path.  They  Imply  that 
the  constraint  blocking  the  path  is  not  due  to  Interaction, 
but  rather  to  direct  user  intent.  The  program  should  not 
disturb  user  intent,  since  its  only  purpose  In  changing  the 
environment  is  to  debug  the  existing  model.  It  now  has  a 
GOOD  REASON  to  stop  changing  the  environment,  so  It  stops. 
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Its  current  line  of  attack  Is  said  to  "fall"  (In  Its  attempt 
to  brlnp,  about  the  desired  change).  Thus#  the 
problem-solver's  activities  leave  a  line  of  *G0AL's  attached 
to  BAD  REASON'S  ending  In  a  *GOAL  attached  to  a  GOOD  REASON 

(1)  .  Now  what  does  all  of  this  have  to  do  with  debugging? 
Simply  this:  the  program  has  now  tried  to  overcome  every 
Interaction-based  constraint  In  the  way  of  producing  the 
user's  desired  state.  It  has  reached  a  user-desired 
constraint  which  Is  the  root  cause  of  all  of  the 
Interaction-based  constraints.  Therefore,  It  has  reached 
the  end  of  the  1  Ine  and  cannot  produce  the  user's  desl red 
state .  There  can  be  three  reasons  for  this  state  of 
af f a l rs : 

(1)  The  user's  desired  state  Is  off-base:  he  has  set 
the  model  an  Impossible  task 

(2)  One  of  the  user's  original  Intentions  Is  wrong; 
i.e.,  one  of  the  root  constraints  Is  the  bug 

(3)  One  or  more  of  the  Interaction-based  constra’nts 
between  the  root  constraints  and  the  desired  state  are 
Incorrect:  the  model  has  an  Interaction  bug 

It  is  obvious  from  what  has  been  said  before  that  the 
program  thinks  that  possibility  (3)  is  the  most  likely.  It 
therefore  suggests  that  one  or  more  of  the  Interactive 
constraints  (noted  by  BAD  REASON'S)  are  caused  by  the  bug. 


(1)  Except  for  the  *EVENT-TRI GGERED-SCHEDULE  case  discussed 
In  4. 4. 2. 3. 
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That  Is,  given  that  the  Interaction  constraints  are  wrongly 


causing  the 

discrepancy,  the  debugger's 

job  Is  to 

f  i  nd 

the 

part  of  the 

mode  1 

which  gives  rise 

to 

the 

faul  ty 

constra Ints. 

This 

Is  then  suggested 

as  the  "bug 

"  In 

the 

user' s  model . 

If  the 

user  doesn't  agree 

wl  th 

any 

of 

the 

program's  suggestions  based  on  possibility  (3),  the  program 
falls  back  on  (2),  and  finally  (1).  Anyway,  let's  pick  up 
the  process  again  at  the  posslbllty  (3)  suggestion  phase. 

The  program  now  has  the  location  of  the 
bug  bracketed  between  the  beginning  and  end  of  a  "line  of 
attack".  Furthermore,  the  submodels  which  could  have  caused 
the  bug  have  been  narrowed  down  to  a  relatively  smalll 
"Interaction  group"  (the  union  of  all  submodels  mentioned  In 
the  bracket)  (1)  .  The  program  must  now  pick  out  the 


(1)  The  size  of  the  "bracket"  and  "Interaction  group"  of 
course  depends  on  the  model.  However,  In  the  experience  I 
have  had,  the  relevant  groups  have  been  small:  a  few  BAD 
REASON'S  and  thus  slightly  more  possible  submodels.  In  the 
case  of  higher-order  stuff,  the  group  gets  somewhat  larger. 
There  Is  no  reason  to  expect  brackets  or  Interaction  groups 
to  get  much  larger  for  larger  models:  the  key  factor  In 
determining  their  size  Is  the  amount  of  control  the  user 
exercises  over  his  model  (In  MSL,  the  extent  to  which  things 
are  determined  by  *SCHEDULE ' s ) .  Control  means  GOOD  REASON'S 
and  thus  short  paths  between  Initial  manifestations  of  a 
discrepancy  and  GOOD  REASON'S  to  close  the  bracket.  Control 
also  means  smaller  groups  of  submodels  which  can  affect  the 
timing  and  resource-allocation  of  other  submodels.  Since 
managers  (and  modellers)  exert  considerable  control  over 
their  systems,  the  amount  of  uncontrolled  Interaction 
possible  In  any  realistic  model  Is  probably  quite 
reasonabl e-c I  zed.  This  In  turn  means  that  brackets  and 
Interaction  groups  should  also  stay  reasonable-sized. 
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submodels  !n  the  "group"  which  caused  the  BAD  constraints  In 
the  "bracket" 

Sometimes  this  is  quite  easy:  all  of  the 
BAD  REASON'S  are  traceable  to  a  single  submouel  Interaction. 
Examples  of  this  are  the  *EVENT  which  triggers  an  *ACTIVITY 
at  the  wrong  tine,  the  ^ACTIVITY  which  constantly  steals 
resources  from  other  necessary  ^ACTIVITY'S,  and  the 
♦ACTIVITY  which  is  always  too  late  (too  early)  to  allow 
another  *ACTIVITY  to  be  Initiated  on  time.  The  program 
looks  for  these  single-cause  Interactions  by  scanning  the 
BAD  REASON'S  In  the  bracket,  looking  for  "give-away"  BAD 
REASON'S  like  * EVENT-DEPENDENT-SCHEDULE  or  consistencies  In 
the  "offending  *ACTIVITY's"  and  "Interloping  ^ACTIVITY'S" 
listings.  If,  in  the  process  of  examining  the  bracket,  the 
debugger  finds  a  single  such  cause  for  the  BAD  REASON'S  of 
the  bracket.  It  immediately  labels  the  faulty  Interaction 
(l.e.,  the  submodels  involved  In  the  interaction)  as  the  bug 
for  that  bracket,  and  flies  It  away.  Often,  however.  In 
looking  at  the  BAD  REASON'S  of  a  bracket,  the  program  finds 
that  a  particular  BAD  REASON  could  have  been  caused  by  any 
of  several  Interactions.  For  example,  ^ACTIVITY  A  couldn't 
be  scheduled  because  B  stole  Its  resources,  or  because  C 
caused  D  to  be  late  so  that  D  couldn't  provide  the  necessary 
resources  for  A.  The  program  handles  this  by  noting  each 


Page  118 


cause  sep-  ratel y  as  a  bug. 

Sometimes  t h i  _►  straightforward  process 
breaks  down:  the  program  Is  unable  to  pick  out  the  cause  for 
th»  BAD  constraints  of  a  bracket  (this  happens  mostly  In 
♦  AND's  and  (especially)  ♦GROUP's).  Currently,  the*  program 
simply  presents  the  troublesome  bracket  to  the  user  telling 
him  that  "there's  something  wrong  In  there".  I  consider 
this  an  Incomplete  part  cf  the  program  (see  4.5). 

When  the  program  has  found  the  bug  (or 
the  few  bugs)  for  each  bracket.  It  presents  them  to  the  user 
In  order  of  "likelihood".  The  debugger's  model  of  the 
likelihood  that  a  suggested  bug  Is  actually  a  bug  In  the 
model  Is 


(1)  The  more  spec  I f 1c  the  suggested  bug,  the  more 
likely  It  Is  that  It  Is  genuine;  thus,  bugs  like 
♦EVENT-DEPENDENT-SCHEDULE  which  correspond  to  a  single 
BAD  Interaction  are  suggested  first. 

(2)  The  more  definite  a  suggested  bug,  the  more  likely 
It  Is;  I.e.,  brackets  which  contain  a  single  possible 
bug  are  suggested  before  those  with  multiple  bugs, 
which  are  in  turn  before  those  which  are  just  brackets 
with  the  "something's  wrong"  tag. 
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(3)  The  mcr?  Interactions  encompassed  by  a  single  bug, 
the  more  likely  It  Is;  this  Is  just  a  recursive 
application  of  Murphy's  law. ..the  more  Interaction 
decisions  a  user  has  to  make,  the  more  he'll  b1ow--thus 
♦AND  bugs  (1)  and  long  timing  chain  bugs  (A  was  late 
for  B  was  late  for  C  was...)  come  early. 

(4)  Timing  bugs  are  more  likely  than  resource-conf 1  let 
bugs;  PRIORITY  determinations  are  much  closer  to  local 
specifications,  and  are  thus  more  likely  to  be 
user- i ntended  than  the  mul t I -T I ME-SL I CE  machinations  of 
a  timing  bug. 


(5)  *GROUP  bugs  are  saved  for  last. 


(6)  After  al 1 

of  the  bugs 

due  to  Interactlor 

are 

gone. 

the  program 

works  on  the  second 

poss 1 b 1 1 

Ity 

stated 

above-- 1 .e . , 

It  starts 

suggest l ng 

that 

the 

GOOD 

const  ra Ints 

are  faulty 

( 1  .  e  . , 

wrong 

♦SCHEDULE 

sped  f  Icat  Ion 

,  etc.); 

It  starts  with 

the 

* EVENT- DEPENDENT-* SCHEDULE 

GOOD 

REASON 

If 

It's 

r round —  It's 

suspic lous. 

(1)  *GROUP  bugs  would  be  here  too,  except,  as  1  mentioned  In 
4. 4. 2. 3,  for  the  fact  the  mechanism  for  handling  them  Is 
rather  dubious. 
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(7)  The  program  suggests  missing  submodels  (see  4.5). 

Thus,  the  program  goes  through  Its  suggestion  repertore  bug 
by  bug,  providing  the  user  with  an  orderly  statement  of  what 
the  program  thinks  might  be  wrong  with  the  model  (see 
section  2  for  the  format  of  the  suggestions).  The  user  can 
always  ask  to  see  the  Interaction  path  leading  to  a  bug,  the 
bracket  of  a  bug,  and  any  other  bugs  which  pertain  to  a 
particular  bracket. 

If  the  user  does  not  agree  with  ary  of 
the  bugs  suggested,  the  program  will  suggest  possibility 
(1):  that  his  original  *G0AL  was  wrong.  If  the  user  Is 
still  unsatisfied  after  all  this  work,  the  program  Informs 
him  as  to  the  location  of  his  head  and  logs  him  out. 

4 . 5  Don 1 1  confuse  m£  with  the  is  ,ts 

Most  of  the  program's  knowledge  about 
models  Is  contained  In  Its  conceptions  of  MSL  (Including, 
for  example.  Its  Ideas  of  how  to  INCREASE  MSL  quantities) 
and  Its  notions  of  user  Intent  Ion — as  discussed  In  4.4. 
However,  as  I  mentioned  In  section  2,  It  Is  useful  from  a 
debugging  point  of  'Mew  to  include  actual  "world"  knowledge 
of  business  games.  Clearly,  this  knowledge  can  be  used  to 
suggest  bugs  which  transcend  the  MSL  specification. 
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This  Is,  in  fact,  the  only  use  the 
current  program  has  for  WOBG  knowledge.  As  shown  In  section 
2,  the  program  has  a  facility  for  suggesting  "missing"  parts 
of  an  MSL  specification.  This  comes  from  a  (very  simple) 
model  of  what  an  MSL  model  of  a  business  game  (1)  coul  d 
contain.  The  program  simply  checks  at  various  points  to 
see  whether  the  addition  of  an  *ACTIVITY  could  solve  some 
problem  (usually  alleviate  some  defflclency)  in  the  user's 
model  Thus,  when  there  Is  a  lack  of  CASH  In  the  sample  run 
In  section  2,  the  program  notes  that  the  addition  of  a 
FACTORING  *ACTIVITY  (see  description  in  Appendix  A  and 
specification  in  Appendix  B)  could  solve  the  problem. 

While  this  sort  of  thing  is  certainly 
useful,  it  is  only  a  "zeroeth  order"  attempt  at  using  world 
knowledge  in  debugging.  A  more  Important  use  of  WOBG 
knowledge  would  be  to  aid  in  finding  bugs  within  the  MSL 
specification  (l.e.,  the  same  kind  of  bugs  the  program  now 
finds).  As  1  mentioned  in  4.4,  a  major  determiner  of  the 
efficacy  of  the  debugging  program  Is  the  number  and  size  of 
the  "brackets"  which  enclose  possible  bugs.  in  the  current 
program,  brackets  are  determined  by  the  amount  of 
uncontrolled  interact lon--i .e . ,  a  purely  MSL-level 
criterion.  in  a  more  thorough-going  approach,  WOBG 


(1)  in  fact,  it  is  based  entirely  on  the  game  in  Appendix  A 
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knowledge  could  he  used  to  determine  which  interactions  are 
really  natural  and  which  are  possible  bugs  (1)  --thus 
limiting  or  even  eliminating  brackets.  Also,  WOBG  knowledge 

could  be  used  to  suggest  suspiciously  specified  ♦ACTIVITY'S, 
etc . 

The  main  reason  that  I  have  not 
exploited  WOBG  knowledge  in  these  more  sophisticated  ways  is 
that  it  has  not  been  necessary  for  the  models  I  have 
investigated  so  far.  Furthermore,  it  is  interesting  to  see 
how  far  a  "doma in- independent"  (2)  debugger  can  go  toward 
finding  bugs  in  MSL  models.  Thus,  WOBG  knowledge  does  not 
enter  into  the  main  bug-finding  process  at  all.  Its  sole 
use  is  In  suggesting  the  addition  of  *ACTIVITY's  to  the 
current  model  (3)  . 


(1)  This  sort  of  thing  Is  actually  found  to  some  degree 
the  programs  of  Sussman  |18|  and  Goldstein  |5|. 

HACKEFM18  |Sman's  dlscusslon  of  the  doma  i  n- i  ndependence 


i  n 

of 


(3)  It  operates  off  a  WOBG  database  which  will  not  be 

h°,r!-  u  lt  work?  3  1ot  ,,ke  MAPL  '10l'  and  was  in 
fact  designed  to  be  compatible  with  the  larger  MAPL  database 
of  Prctosys tem  1  (the  WOB  |9|). 
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5  Conclusions 

I  would  like  to  use  this  concluding 
section  to  fit  my  mode  1 -debugg I ng  system  Into  the  "big 
picture",  viewing  It  first  as  a  debugging  tool,  and  second 
as  part  of  an  automatic  programming  system. 

The  approach  of  my  debugging  system 
should  be  seen  as  one  method  of  the  several  which  can  be 
used  by  the  human  or  machine  problem-solver.  The 
s Imul ate-and- I nves t I gate  technique  shown  here  Is  useful  for 
debugging  poorly  understood  but  easily  modelled  systems.  It 
requires  the  modeller's  knowledge  and  lack  of  knowledge  to 
be  of  a  certain  character,  as  outlined  earlier.  It  Is  also 
most  useful  for  handling  highly  Interactive  systems.  If  the 
problem  domain  Is  very  well  understood,  or  If  actions  In  It 
are  basically  Independent,  other  techniques  are  simpler  and 
much  better. 

Furhtermore,  It  should  be  stressed  that 
the  debugging  methods  of  the  program  are  quite  naive  In  the 
context  of  a  real  ( I . e . ,  non-game)  Interactive  system.  It 
Is  almost  certain  that  all  of  the  techniques  described  here 
would  have  to  be  shored  up  with  procedures  based  on 
knowledge  of  the  problem  domain  (see  4.5).  Remember  that 
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the  basic  "smarts"  of  my  system  Is  In  the  expl orat Ion  of  the 
simulation  history.  In  real  life,  this  exploration  phase  Is 
usually  preceded  by  some  knowldgable  guess  work  on  the  part 
of  the  debugger:  almost  all  expert  human  debuggers 
(programmers/  consul tants, etc . )  start  their  exploration  for 
a  bug  with  a  good  preconceived  notion  of  the  nature  of  the 
bug.  This  "notion"  comes  from  the  utilization  of  long 
experience  about  what  kind  of  bugs  are  attached  to  what  kind 
of  problems;  most  debuggers  know  that  only  one  or  two  things 
could  possibly  cause  a  bug  at  any  given  time  In  their 
exploration.  No  one  yet  know:,  how  to  encode  this  key 
experiential  knowledge  into  a  computer  program.  Certainly, 
no  attempt  has  been  made  In  this  thesis. 

Thus,  the  program  presented  here,  when 
viewed  only  as  a  general  debugging  technique,  should  be  seen 
as  part  of  a  larger  system:  It  fits  in  after  an  Initial 
"guesswork"  phase  (as  one  of  several  possibly  applicable 
techniques)  and  just  before  a  "weeding  out"  ph?*se  which 
makes  thorough  use  of  knowledge  In  the  problem  domain  to 
narrow  down  the  choice  of  possible  bugs. 

The  model -debugg I ng  needs  of  an 
automatic  programming  system  are  somewhat  different.  Here 
the  user  is  Interested  In  expressing  a  model  of  his  problem 
to  the  machine  In  such  a  way  that  he  can  be  sure  that  the 
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machine  understands  It  properly.  Thus,  after  a  phase  of 
model  specification  aid  at  def 1 ne-t Ime  (1)  ,  a 
model -debugg I ng  system  like  the  one  here  can  come  In  and 
demonstrate  the  APS's  Idea  of  the  model  to  the  user's 
satisfaction  (and  help  the  user  overcome  any  d Ic repancys ) . 
The  s Imul ate-and- Invest Igate  and  doma In- I ndependence 
philosophies  of  my  system  are  well-adapted  to  this  purpose: 
the  system  can  afford  to  be  an  expert  In  Its  own  modelling 
language  and  do  a  great  deal  of  exploration  work  In  finding 
bugs.  Furthermore,  the  user  can  tolerate  a  reasonable 
number  of  program-generated  choices  of  bugs  In  his  model  If 
he  can  be  certain  of  eventual  understanding  by  the  APS. 
Therefore,  I  think  that  the  techniques  used  here  might  find 
direct  application  In  automatic  programming. 

Nonetheless,  for  a  debugger  to  be  truly 
useful,  whether  In  an  automatic  programming  or  general 
artificial  Intelligence  environment.  It  must  Incorporate  the 
same  kind  of  experiential  debugging  knowledge  found  In  the 
human  expert.  This  kind  of  stuff  will  surely  be  the  basis 
of  the  next  generation  of  debuggers  which  are  now  on  the 
hor I zon . 


(1)  See  | 9 |  for  Protosystem  I's  "activity  expert  modules". 
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Appendix  A 


The  following  Is  excerpted  from  the 
article  "Business  Games--P1ay  One!"  by  G.R.  Andl Inger  In  the 
Harvard  Business  Review  for  March-Aprll,  1958  (  (c)  The 
President  and  Fellows  of  Harvard  Un Iversl t  y )  —  1 1  s 
reprinted  by  permission. 

It  serves  as  an  example  of  the  kind  of 
business  games  at  which  the  program  (and  MSL)  are  directed, 
An  MSL  model  of  the  game  described  here  appears  In  Appendix 
B. 
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Business  Games--Play  One! 


Basic  Objectives 


Games  are  as  old  as  man.  Usually/  their 
basic  objective  Is  entertainment.  The  Business  Management 
Game/  however/  alms  not  at  entertainment,  but  at  learning. 
Other  differences  between  It  and  a  game  like  Monopoly,  for 
example,  are: 

--The  degree  to  which  It  approaches  reality. 

--The  degree  to  which  the  players' 
experience,  judgment,  and  sk!ll--as  opposed  to  luck-- 
Influence  the  outcome. 

If  any  business  game  Is  to  serve  a  puroose  beyond 
that  of  a  fascinating  toy  ,  there  must  be  some  transfer  of 
learning  from  the  game  situation  to  reality.  While  there 
probably  Is  some  such  transfer  from  playing  a  generalized 
business  game  that  mirrors  "any  company"  and  not  a 
particular  firm,  an  executive  could  derive  Infinitely 
greater  benefit  from  a  game  that  permits  him  to  practice 
guiding  the  destiny  of  his  own  company  or  one  In  his  own 
lndustry--whlch  unfortunately.  Is  unavailable  at  this  early 
sta^e  of  business  gaming.  The  success  of  specific  war 
games,  which  the  military  has  been  using  for  years  to 
simulate  combat  situations  for  training  officers,  however, 
holds  great  promise  for  similar  applications  In  business  In 
due  course. 

The  Business  Management  Game  Is  a  case 
In  point.  We  started  It  In  1956  with  the  Idea  of  applying 
war-gaming  techniques  to  business.  In  the  course  of  the 
year  we  tested,  modified,  and  retested  the  game  many  times 
to  develop  a  fine  balance  between  realism  and  playability. 
The  more  closely  a  game  resembles  reality,  the  more 
cumbersome  It  becomes--unt  1 1  It  Is  no  longer  playable. 
Hence,  there  Is  a  need  to  compromise.  Also,  we  designed 
the  game  to  be  relatively  stable.  Ho  extreme  strategy  can 
result  In  sudden  success;  yet  players  can  gain  outstanding 
success  If  they  are  good  enough--or  bankruptcy  If  they  are 
not  careful . 

The  game  Is  partly  deterministic  and 
partly  probabilistic.  Some  results  are  determined  directly 
by  the  action  of  the  players;  others  are,  to  varying 
degrees,  subject  to  chance  or  probability.  The  weight  of 
the  elements  of  the  game  Is  such  that  the  longer  the  game. 
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the  smalller  the  Influence  of  luck. 


Rules  of  Play 


In  this  section  I  shall  give  a  brief 
general  description  of  each  game  element  and  the  specific 
values,  rules  and  probabilities  that  define  each  element  In 
quantitative  terns.  Instructions  for  the  umpires  are 
Included  at  each  point;  but  remember  that  they  should  not  be 
given  to  the  players. 

The  Market 


The  market  Is  made  up  of  24  customers.  Each 
customer's  potential  Is  different;  In  any  one  time  period,  a 
few  customers  are  not  buying  any  units,  while  others  may  buy 
four  or  five  units  (at  $10,000  per  unit)  If.  a  salesman  Is 
able  to  make  a  sale. 

The  market  Is  dynamic,  so  the  customer 
potentials  change.  If  the  market  Is  growing,  they  change 
upward;  should  the  market  be  hit  by  a  recession,  however, 
they  may  drop  drastically.  The  long-term  trend  of  the 
market  Is  announced  to  the  players;  short  term  fluctuations 
are  not.  If  a  company  Is  Interested  In  finding  out  what  the 
total  market  potential  Is  In  any  time  period,  a  $2000 
expenditure  for  market  research  will  buy  this  Information 
from  the  umpires. 

The  24  customers  divide  geographically 
Into  four  regions  on  the  game  board,  each  region  containing 
six  accounts.  This  geographical  division  allows  the  company 
to  do  local  advertising  (see  the  section  on  "Advertising  the 
Product")  and  conduct  market  research  In  only  one  region  at 
a  time.  Such  market  research,  which  tells  a  company  the 
potential  of  each  customer  In  the  region  and  permits  the 
pinpointing  of  the  direct  selling  effort  (see  the  section  on 
"Marketing  the  Product"),  may  be  obtained  by  paying  the 

umpires  $30,000  for  "staff  work." 

In  addition  to  the  separation  Into 
geographical  regions,  the  market  breaks  down  Into  one  rural 
and  two  urban  markets.  The  significance  of  this  distinction 
Is  that  In  an  urban  market,  where  a  salesman  can  make  more 
calls  per  day,  he  has  two  chances  of  making  a  sale  during 
each  time  period,  while  In  the  rural  market  he  has  only  one 
chance . 

If  at  the  end  of  a  year  a  company 
desires  to  find  out  what  portion  of  the  total  market  It  has 
been  able  to  capture.  It  may  but  a  share-of-market 
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Information  from  the  umpires  for  $2000. 

The  umpire  should: 


(1)  Keep  a  list  of  all 

(2)  Distribute 
comes  to  $360,000  at 
the  24  customers  as  follows: 

1  account 

3  accounts 
5  accounts 
13  accounts 

2  accounts 


current  account  potentials. 

customer  potential,  which 
the  game,  at  random  to 

$40,000 
30,000 
20,000 
10,000 
0 


a  total 
the  beginning  of 


(3)  Depending  on  the  economic  climate  determined 
In  advance,  change  these  starting  potentials  as  the  game 
progresses  as  follows: 


— For  slow  growth,  chane  one  account  each  quarter 
at  random.  Move  ahead  on  the  random  number  table 
until  a  number  between  01  and  24  appears,  then  add 
$10,000  to  the  potential  of  that  account  number. 

--For  faster  market  growth,  change  two  or  three 
accounts  In  the  same  mannner  as  above  for  each 
quarte  r. 

--For  a  depression,  change  half  or  all  of  the 
accounts  to  zero  for  one  or  more  quarters. 

(4)  If  a  company  decides  to  buy  market  Information 
(total  potential,  market  research,  or  share  of  market), 
write  the  Information  on  a  slip  of  paper  and  pass  It  to  the 
company. 


Marketing  the  Product 


Units  are  sold  by  salesmen,  who  call  on 
the  24  accounts  In  the  market.  In  an  urban  market  a 
salesman  may  make  two  calls  per  quarter;  and  In  a  rural 
market,  only  one. 

In  the  presence  of  an  umpire,  the  sales 
manager  of  a  company  points  to  the  accounts  he  wants  to  call 
on.  The  umpire  will  tell  him,  after  examining  the  random 
number  table,  whether  a  sale  Is  made  or  not.  How  many 
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units  are  sold  to  a  customer  will  depend  on  competitive 
action.  The  completed  decision  form,  returned  to  the 
company  at  the  end  of  the  particular  period,  contains  the 
actual  sales  results  by  accounts. 

Whenever  a  salesman  has  two  calls,  he 
must  make  the  second  call  on  n  any  of  the  three  to  eight 
accounts  adjacent  to  the  flrsc  square  called  on;  that  Is,  he 
may  not  jump  accross  territories.  If  no  sale  Is  made  on  the 
first  call,  he  may,  of  course,  call  on  the  same  account 
again  during  the  same  quarter.  Furthermore,  there  Is  no 
limit  to  the  number  of  salesmen  who  may  call  on  the  same 
account  In  one  time  period.  Between  quarters,  salesmen  may 
be  moved  to  any  accounts  that  the  company  wishes  to  cover 
during  the  next  quarter. 

Each  time  a  salesman  makes  a  call,  he 
has  a  certain  fixed  probability  of  making  a  sale.  This 
chance  of  making  a  sale  may  be  Increased  In  one  of  three 
ways  or  a  combination  thereof: 

--A  company  may  Intensify  Its  direct  selling 
effort  by  having  more  than  one  salesman  cover  one 
account  as  described  above.  In  such  a  case.  If 
the  first  salesman  makes  a  sale,  the  second  one 
may  move  to  any  adjoining  account  for  his  calls. 

--A  company  may  support  the  salesman's  effort  by 
advertising  (see  "Advertising  the  Product"). 

--A  company  may  attempt  to  Improve  Its  product  by 
spending  more  money  for  a  research  and  development 
effort  (see  "Research  and  Development"). 

Every  salesman  costs  $10,000  to  hire  and 
then  $1000  per  quarter  In  slary.  (Since  the  product  he  will 
be  selling  Is  a  hlgh-prlce,  complicated  unit.  It  takes  one 
year  to  train  a  salesman  before  he  can  be  sent  out  Into  the 
field.)  There  Is  a  possibility  that  a  salesman  will 
resign.  In  which  case  the  umpire  Informs  the  company  of  this 
loss . 

The  umpire  should  have  the  following 
Instructions  for  marketing: 

(1)  Each  period  there  Is  a  chance  of  loss  for 
each  salesman.  Move  ahead  on  the  random  number  table  as 
many  numbers  as  the  company  has  salesmen;  If  one  or  more  of 
these  numbers  Is  .05  or  less,  the  company  loses  one  or  more 
salesmen. 

(2)  In  an  urban  market,  allow  two  calls  per 
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quarter;  In  a  rural  market,  only  one  call. 

(3)  A  salesman  always  has  a  25%  chance  of  making  a 
sale.  For  each  call,  examine  the  next  number  on  the  random 
number  table.  If  the  number  Is  25  or  less,  then  a  sale  has 
been  made;  If  It  Is  26  or  more,  no  sale  Is  made. 

Advertising  the  Product 

Product  advertising  In  a.iy  quarter 
Increases  the  salesmen's  chances  of  amklng  a  sale.  It 
covers  only  the  region  or  regions  (1,11,111,  and  IV  on  the 
game  board)  that  the  company  designates,  and  Is  effective  In 
the  current  quarter  only.  Advertising  costs  $3000  per 
page,  and  a  company  may  buy  up  to  five  pages  of  advertising 
In  any  region  In  any  quarter. 

Here  are  the  umpire's  Instructions: 

For  each  sales  call  within  the  reglon(s)  In  which 
the  company  has  advertised,  go  to  the  next  number  In  the 
random  number  table  and  determine  whether  or  not  there  Is  a 
sale  according  to  the  probabilities  In  the  following  table. 
If  the  number  Is  the  same  or  below  the  probability 
percentage,  a  sale  Is  made. 


Pages 

Amount 

Probab I 1 l ty  of 

0 

0 

25% 

1 

$3,000 

29 

2 

6,000 

35 

3 

9,000 

42 

4 

12,000 

48 

5 

15,000 

52 

Research  and  Development 


If  a  company  can  develop  a  superior 
product.  It  gains  a  competitive  advantage.  Usually, 
research  and  development  have  to  be  fairly  continuous  to 
achieve  a  product  Improvement,  but  a  "crash  program"  may 
yield  results  In  a  relatively  short  time.  The  minimum 
research  effort  per  quarter  costs  $10,000,  but  a  company  may 
Invest  more  than  that  In  multiples  of  $10,000. 

The  umpire  notifies  the  company 
Immediately  when  Its  research  and  development  program  has 
produced  results,  and  all  units  scheduled  for  production  In 
that  quarter  are  considered  to  be  equipped  with  the 
Improvement.  To  find  out  the  extent  to  which  customers  wll 
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prefer  an  Improved  product,  $5,000  of  market  research 
(obtained  from  the  umpires)  Is  needed. 

Of  course,  these  ground  rules  can  be 
altered  to  fit  a  company's  situation  more  cl osel y--j ust  as 
the  ground  rules  for  other  aspects  of  the  Business 
Management  Game  can.  A  company  manufacturing  equipment  for 
railroads  may  well  want  to  use  different  units  of  research 
expenditure  than  would  a  company  making  dies  for  plastic 
products.  The  length  of  time  necessary  to  get  results  from 
research  also  varies  greatly  from  company  to  company,  as 
does  the  cost  of  research  to  measure  customer  reactions  to 
new  products.  These  and  other  rules  can — and  In  many  cases 
should--be  tailored  to  the  realities  of  the  Industry. 

The  umpires  will  tell  a  company  as  soon 
as  a  competing  team  Introduces  an  Improved  product  In  the 
market.  The  players  can  then  counter  with  a  stepped-up 
marketing  effort  or  a  crash  research  and  development 
prog  ram. 

If  a  company  Is  Interested  In  finding 
out  the  total  Industry  research  and  development  expenditures 
for  the  past  year,  such  Information  Is  available  from  the 
ump I  res  for  $1,000. 

In  addition,  the  umpires  should: 


(1)  Maintain  a  cumulative  account  of  each 
company's  expenses.  After  each  break  In  continuity  (a 
quarter  without  any  R  &  D  expenditures)  and  after  each 
product  Improvement,  start  the  accumulation  over  again. 

(2)  Make  appropriate  revisions  of  the  probability 
of  Improvement.  The  cumulative  dollar  amount  spent  on 
research  and  development  determines  the  chai ces  a  company 
has  for  obtaining  a  product  Innovation.  Examine  the  random 
number  table;  If  the  next  number  Is  the  same  as  or  below  the 
probability  percentage,  an  Improvement  Is  achieved. 

Cumulative  amount  Probability  of  Improvement 

$10,000 
20,000 
30,000 
40,000 
50,000 
60,000 
70,000 
80,000 
90,000 

100,000  and  over 


0% 

0 

0 

2 

4 

7 

11 

15 

18 

20 
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(3)  Whenever  a  company  achieves  an  Improved 
product#  Increase  all  Its  sales  probability  percentages  by 
10.  For  example/  If  Company  A  has  an  Improved  product/  this 
Is  the  result: 

Probability  of  sale 
Old  product  25% 

Improved  product  4lo 

3?% 

If  Company  A  spends  $6000  on  advertising  In  one 
region  and  has  an  Improved  product/  this  Is  the  result  In 
that  region: 

Probability  of  sale 
Old  product  with 

two  pages  of  advertising  35% 

Improved  product  +10 

45% 

(4)  As  soon  as  all  three  companies  have  Improved 
products  on  the  market/  cancel  the  premium  of  10  for  all 
three . 

(5)  If  one  company  achieves  two  product 
Improvements  before  one  or  both  of  Its  competitors  have 
achieved  any.  Increase  all  Its  sales  probability  percentages 
by  20. 

Increasing  Production 

The  Initial  plant  which  each  company 
must  build  costs  $150/000/  and  has  a  maximum  throughput  of 
5  units  each  quarter.  From  then  on  a  company  may  add  other 
production  lines  for  $30#000  each.  But  each  such  $30,000 
Increment  will  Increase  the  maximum  throughput  by  5  . 

A  company  must  pay  for  Increased 
capacity  as  soon  as  It  decides  to  start  construction. 
Construction  time  Is  nine  months  (three  time  periods),  and 
only  after  completion  may  the  first  unit  be  put  Into  "work 
In  progress"  for  the  new  production  line.  The  companies 
are  not  allowed  to  sell  or  otherwise  dispose  of  excess 
capacity. 

The  total  lead  time  In  producing  units 
In  a  company's  plant  Is  six  months.  First,  production  Is 
scheduled,  and  this  Involves  no  financial  outlay.  Then  In 
the  next  quarter  units  are  put  Into  "work  In  progress"  and 
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must  be  paid  for.  In  the  subsequent  quarter  these  units 
come  off  the  production  line  ,  are  added  to  Inventory,  and 
may  be  sold. 


Total  production  cost  contains  a  fixed 
cost  and  a  variable  element.  The  fixed  cost  Is  Incurred 
each  quarter,  regardless  of  how  many  units  are  produced.  At 
a  maximum  capacity  of  five  units  per  quarter,  the  fixed  cost 
Is  $6000,  and  the  variable  cost  per  unit  Is  $3000.  As 
capacity  Is  Increased  by  additional  production  lines,  fixed 
costs  rise  and  the  variable  cost  per  unit  decreases.  If  a 
company,  prior  to  adding  a  line,  wants  to  know  the  exact 
costs  It  will  Incur  at  the  next  level  of  capacity.  It  can 
get  that  Information  from  the  umpires  for  $2000,  but 
otherwise  the  umpires  will  Inform  the  company  what 
production  costs  are  when  the  new  line  goes  Into  production. 

Units  are  added  to  Inventory  at  actual 
cost.  When  a  unit  Is  sold,  however.  It  Is  deducted  from 
Inventory  at  the  average  cost  (  total  Inventory  Investment 
divided  by  number  of  units  In  Inventory). 

rhe  umpires  should  calculate  the 
production  costs  at  various  capacity  levels  as  follows: 


capac I ty 

Total  unit 

cost  Fixed  cost 

Variable  cost 

per  quarter 

per  unit 

5 

$4,200 

$6,000 

$3,000 

10 

3,600 

14,400 

2,200 

15 

3,000 

22,500 

1,500 

20 

2,400 

28,800 

1,000 

25 

1,800 

31,500 

600 

Financial  Management 

The  mi  lagement  of  a  company's  available 
capital  Is  of  critical  Importance.  Each  company  starts 
with  $400,000  capital  and  grow  only  through  reinvested 
earnings.  Profitability  will  be  In  direct  relation  to  the 
skill  with  which  the  various  parts  of  the  business  are  kept 
In  harmony  with  each  other  to  achieve  sound  growth. 

The  price  per  unit  of  product  Is  fixed 
at  $10,000.  When  a  sale  Is  made,  accounts  receivable  are 
Increased  by  the  total  amount  of  the  sale,  and  on  the  game 
board  an  accounts  receivable  symbol  Is  placed  on  the  fifth 
space  In  the  "accounts  receivable"  column.  Every  quarter 
this  symbol  Is  moved  up  one  space  until  after  four  quarters 
It  reaches  the  top  space  and  becomes  cash.  Competitive 
pressure  In  the  Industry  forces  the  extension  of  credit; 
hence  the  one  year  collection  lag. 

If  a  company  Is  short  of  cash,  accounts 
receivable  may  be  factored  to  get  cash  Immediately.  The 
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cost  of  doing  this  Is  20%  of  the  amount  factored. 
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Appendix  B 


The  following  Is  an  MSL  model  of  parts 


of  the  game 

( for 

_  _  „  n 

one 

region")  described 

In  Appendix 

A- 

-as 

seen  from 

the 

point 

of  view 

of  a 

player  wishing 

to 

1 nvest 1  gate 

the 

game 

and  see 

the  effects  of 

various 

st  rategles. 

It 

Is  presented  here 

as  an 

l 1 1 ustrat Ion 

of 

the 

use  of  MSL. 


(•ACTIVITY  HIRING 

(•PREREQUISITES  ( *PRESENT  (1000  CASH))) 
(•SCHEDULE  ON  CALL) 

(•PRIORITY  2) 

(•OUTPUT  (SOME  TRAINEE)) 

(•TAKES  0) 

) 

(•ACTIVITY  TRAINING 

(•PREREQUISITES 

(AND  ( *PRESENT  (1000  CASH)) 

(•PRESENT  (SOME  TRAINEE)))) 

(•TAKES  3) 

(•OUTPUT  (SOME  SALESMAN)) 

) 


(•ACTIVITY  URBAN-CALL 

(♦PREREQUISITES 

(AND  (‘PRESENT  (ASSIGNED 
(SOME  SALESMAN) 

(SOME  URBAN-CUSTOMER)) 
(•PRESENT  (500  CASH)))) 

(♦TAKES  .5) 


) 


(•ACTIVITY  RURAL-CALL 

(•PREREQUISITES 

(AND  ( ‘PRESENT  (ASSIGNED 
(SOME  SALESMAN) 
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(SOME  RURAL-CUSTOMER))) 
(♦PRESENT  (1000  CASH)))) 

(♦TAKES  1) 

) 

(♦EVENT  QUITTING 

(♦CONDITIONS  QUITTING-PROBABI L ITY) 
(♦ACTIVITIES  (SALES-CALL) 

(♦CANCEL) 

(♦REMOVE  (THAT  SALESMAN))) 
(♦ACTIVITIES  (TRAINING) 

(♦CANCEL) 

(♦REMOVE  (THAT  TRAINEE))) 

) 

(♦ACTIVITY  ADVERTISING 

(♦PREREQUISITES  (♦PRESFNT  (3000  CASH))) 
(♦SCHEDULE  ON  CALL) 

(♦OUTPUT  (1  PAGE -OF -ADVERT I S I NG) ) 

(♦PRIORITY  3) 

(♦TAKES  1) 

) 


(♦ACTIVITY  R&D 

(♦PREREQUISITES  ( *PRESENT  (10000  CASH))) 
(♦TAKES  0) 

(♦SCHEDULE  ON  CALL) 

(♦OUTPUT  (10000  R&D) ) 

) 


(♦EVENT 


) 


PRODUCT- IMPROVEMENT 

(♦CONDITIONS  P- 1  - PROBAB I L I TY ) 

(♦ACTIVITIES  ( R&D) 

(♦OUTPUT  (1  PRODUCT- IMPROVEMENT))) 


(♦ACTIVITY  PRODUCT-INITIATION 

(♦PREREQUISITES  ( *PRESENT 

(1  PRODUCTION-LINE))) 

(♦TAKES  1) 

(♦OUTPUT  (5  UNITS-IM -PROGRESS)) 


(♦ACTIVITY  PRODUCT  I ON-COMPLET ION 

(♦PREREQUISITES  (^PRESENT 

(5  UNITS-IM -PROGRESS))) 

(♦TAKES  1) 

(♦OUTPUT  (5  UNITS)) 
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) 

(•ACTIVITY  PRODUCTION-LINE-CONSTRUCTION 

(•PREREQUISITES  ( ‘PRESENT  (30000  CASH))) 
(•TAKES  3) 

(•OUTPUT  (1  PRODUCTION-LINE)) 


(•ACTIVITY  FACTOR 

(•PREREQUISITES  (‘PRESENT  (5000  A-R) ) ) 
(•TAKES  0) 

(•OUTPUT  (4900  CASH)) 

(•SCHEDULE  ON  CALL) 


(•EVENT  SALE 

(•CONDITIONS  SALES-PROBABI LITY) 
(•ACTIVITIES  (SALES-CALL) 

}  ( ‘OUTPUT  (10000  A-R))) 

(•FUNCTION  SALES- PRO BAB  I L I TY 

(•ARGUMENTS  ( PAGE-OF -ADVERT I S ING) ) 
(PRODUCT-IMPROVEMENT)) 

(•RETURN 

(•SUM-UP 

.25 

(AD-FUNCTION 

PAGE -OF -ADVERT  I S I NG) 

(TIMES  .10 

^  PRODUCT- IMPROVEMENT) 

) 

(•FUNCTION  AD-FUNCTION 

(•ARGUMENTS  ( PAGE -OF -ADVERT I S ING) ) 
(•RETURN 

(•TABLE  ( PAGE -OF -ADVERT I S I NG 
•RESULT) 

(0  0)  (1  .04)  (2  .10)  (3  .17) 
.  .23)  (5  .27))) 


(•FUNCTION  P- J  PROBABILITY 
(•ARGUMENTS  ( R&D) ) 

(•RETURN  ( ‘TABLE  (R&D  ‘RESULT) 

((LESSP  RAD  40000)  0)  (40000  .02) 
(50000  .04)  (60000  .07)  (70000  .11) 
(80000  .15)  (90000  .18)  (100000  .20) 
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((GREATERP  R&D  100000)  .20))) 


